Fwd: RFC: TLAB allocation and garbage-first policy

Aleksey Shipilev shade at redhat.com
Wed Sep 20 16:31:57 UTC 2017


On 09/20/2017 06:18 PM, Christine Flood wrote:
> How frequent is it that we end up with 10% full regions which can't fit a
> tlab? 

Frequent enough to fragment the freeset and drive LRUFragger into Full GC, alas.

> You are proposing changing a metric which will no longer distinguish
> between regions which are 100% full with 10% live data and regions which
> are 10% full with 10% live data.  I would argue that those two situations
> should be treated differently most of the time.  In fact in the situations
> where we don't hit this tlab bogosity race condition there is no reason to
> copy that 10% full 10% live data.

Yes, but the race does happen, and thus we have to choose between several evils. For a collector
that optimizes raw copying keeping the region with 10%-full/10%-live is of course beneficial. For a
collector that has to deal with fragmentation too, this becomes much grayer area. My argument was
not about that copying having no cost, it was about that copying having the affordable cost in the
grand scheme of things. And the benefits with having less fragmented heap outweigh that cost.

Your argument seems to imply that G1 does it wrong when it considers "live" for cset selection,
right? This seems to be even more important for G1, because it has to copy during the pause.

> I suspect your proposed metric change would result in most current
> allocation regions being included in the collection set.  This results not
> just in unnecessary copying work, but presumably more triggered write
> barriers because these most recently allocated objects are presumably also
> more likely to be accessed in the near future.

Ok, that's compelling. But the filler object solution also falls victim to this: it will also
inflate garbage in recently allocated and recently retired region, and it will get considered in the
collection set.

All we are left with is trimming the TLABs.

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list