Fwd: RFC: TLAB allocation and garbage-first policy

[Christine Flood]

G1 will trigger a young generation gc when it's designated young regions
are full.

We trigger a GC when we get to a certain allocation threshold which doesn't
really imply anything about how full our current allocation regions are.

Again there is nothing preventing us from writing a heuristic that triggers
when we fill up a certain number of regions, but that isn't what we
currently do.

Christine




On Wed, Sep 20, 2017 at 12:31 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> 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
>
>