GitLab

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}