RFC: TLAB allocation and garbage-first policy
Aleksey Shipilev
shade at redhat.com
Wed Sep 20 12:58:59 UTC 2017
On 09/20/2017 02:44 PM, Christine Flood wrote:
> I can think of several solutions. One would be to cap the max tlab size as we discussed yesterday.
> Having a tlab be an entire region has some nice performance characteristics but isn't really
> necessary, nor is it in the spirit of tlabs.
This seems to work badly for smaller heaps? E.g. we have 512K regions in 4G configuration. Reducing
the TLAB size to, say, 1/10-th of region size makes it only 50K, which is too low? We also do not
want to hit the slowpath allocation (i.e. TLAB refill here) for every 50K allocated, no?
It also seems inconsistent with the previously said goal: (paraphrasing) we try not to make the
allocators pay for our sins. Capping the TLABs seems to be doing exactly that?
> Another potential solution would be to treat these regions specially. When a tlab allocation fails
> in a region we could fill that particular region with a filler array. Therefore we now have
> garbage. This differs from your solution in that regular regions that are perfectly happy with
> normal sized tlab spaces available aren't going to get prematurely compacted.
Aha, sounds interesting. So the only thing that does seem to help is the half-full regions we never
tried to allocate in, right? Otherwise it is the same as looking at "live" for cset selection.
-Aleksey
More information about the shenandoah-dev
mailing list