GitLab

This reverts commit d4e7ee66.

Reason for revert: Broke Lollipop Phone Tester tests.
See below link for details.
https://ci.chromium.org/p/chromium/builders/ci/Lollipop%20Phone%20Tester/26949

Original change's description:
> Reland "base/allocator: Add a thread cache to PartitionAlloc."
> 
> Changes: disabled the thread cache on Windows.
> 
> Original change's description:
> > base/allocator: Add a thread cache to PartitionAlloc.
> >
> > This CL adds a thread cache to PartitionAlloc. It is optional, only
> > applies to thread-safe partitions, and uses the same freelist encoding
> > and bucketing as the main allocator.
> >
> > The thread cache is added "in the middle" of the main allocator, that is:
> > - After all the cookie/tag management
> > - Before the "raw" allocator.
> >
> > That is, the general allocation flow is:
> > 1. Adjustment of requested size to make room for tags / cookies
> > 2. Allocation:
> >   a. Call to the thread cache, if it succeeds, return.
> >   b. Otherwise, call the "raw" allocator <-- Locking
> > 3. Handle cookies/tags, zero allocation if required
> >
> > On the deallocation side, the process is reversed:
> > 1. Check cookies / tags, adjust the pointer
> > 2. Deallocation
> >   a. Return to the thread cache of possible. If it succeeds, return.
> >   b. Otherwise, call the "raw" allocator <-- Locking
> >
> > The thread cache maintains an array of buckets, the same as the parent
> > allocator. A single thread cache instance is only used by a single
> > partition. Each bucket is a linked list of allocations, capped to a set
> > maximum size. Elements in this "freelist" are encoded the same way they
> > are for the main allocator.
> > Only the smallest buckets are eligible for caching, to reduce the
> > memory impact.
> >
> > There are several limitations:
> > - Only a single partition is allowed to have a thread cache
> > - No periodic purging of thread caches is done
> > - No statistics are collected
> >
> > The last two limitations will be addressed in subsequent CLs. Regarding
> > the first one, it is not possible to use Chrome's native thread local
> > storage support, as it allocates. It is also desirable to use
> > thread_local to improve performance.
> >
> > Bug: 998048
> > Change-Id: Ia771f507d9dd1c2c26a4668c76da220fb0c65dd4
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2375206
> > Commit-Queue: Benoit L <lizeb@chromium.org>
> > Reviewed-by: Kentaro Hara <haraken@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#805697}
> 
> Bug: 998048
> Change-Id: I23b70f6964bb297502921d1a08bf128d9093d577
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2404849
> Reviewed-by: Kentaro Hara <haraken@chromium.org>
> Reviewed-by: Benoit L <lizeb@chromium.org>
> Commit-Queue: Benoit L <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#806597}

TBR=haraken@chromium.org,lizeb@chromium.org

Change-Id: Iedf9f99609ccd57e1a0754c8dfd8cda3a5f85539
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 998048
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2410422Reviewed-by: Filip Gorski <fgorski@chromium.org>
Commit-Queue: Filip Gorski <fgorski@chromium.org>
Cr-Commit-Position: refs/heads/master@{#806655}