GitLab

The thread cache has a hard limit on how many objects are cached per
bucket. Previously, every cache fill above the limit would go back to
the central allocator, so the following scenario:
1. 1000 malloc(10) calls
2. 1000 free(ptr) calls (of the previously allocated memory)

Woould acquire the lock 1000 - kMaxCountPerBucket times on the
deallocation path. By batching deallocations, the lock is only acquired
(1000 - kMaxCountPerBucket) / (kMaxCountPerBucket / 2)
  = 2000 / kMaxCountPerBucket - 2 times.

It may also reduce cache footprint for these scenarios, since the bucket
is rarely full. Note that the allocation patth is not affected, batching
on this side may be investigated as well, but not without data showing
that empty buckets are frequent.

Bug: 998048
Change-Id: I626205e28d7a082a12303a493ca504e9581fc43a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2546599
Commit-Queue: Benoit L <lizeb@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#829208}