Reserved space in GC/TLABs

[Roman Kennke]

Am Mittwoch, den 11.01.2017, 10:17 +0100 schrieb Aleksey Shipilev:
> On 01/10/2017 10:36 AM, Roman Kennke wrote:
> > > So, there are few issues:
> > > 
> > > 1) GC/TLAB reserved space means every region has "garbage", which
> > > has 
> > > heuristics implications. We can check for "garbage > 
> > > TLAB::alignment_reserve()" in "aggressive"?
> > > 
> > > 2) More concerning: after mark-compact we can read beyound the
> > > heap, if we
> > > are alloc-prefetching at the last region, near its end. We
> > > probably want to
> > > reserve a region at the end of the heap to handle this?
> > 
> > Is it only an issue with aggressive heuristics? I wouldn't be too
> > concerned
> > about that, aggressive is meant to be used for testing only, and
> > explicitely
> > made to give the GC a hard time (e.g. collect as much as possible,
> > as much of
> > the time as possible, and generally do random- ish things to
> > exercise code
> > paths that are otherwise rarely used)
> 
> My major concern is that "garbage() == 0" condition is not enough to
> disambiguate the regions with no garbage at all.

Yes ok. I don't see what we can do when a TLAB has just been started
but not used yet. At the end of marking, we 'finalize' all active
tlabs, i.e. fill them with a filler object and close them. Maybe it's
possible to recognize when a TLAB is still empty, and reclaim it
instead?

>  I can see the heuristics that
> would not touch the completely live regions, even under drastic
> conditions (e.g.
> all other regions are only 99% full).
> 
> Either interpretation of "aggressive" is only half-way:
> 
>  a) "aggressive" as testing strategy: in the workload example above,
> there are
> two distinct phases in workload, roughly "before mark-compact" and
> "after
> mark-compact". Before mark-compact we always evac "full" regions
> because garbage
> is not zero due to GCLAB allocation. After mark-compact we never evac
> the full
> regions because mark-compact plunged the garbage holes. If we want
> "aggressive"
> to be the testing strategy, then I would say we need to evac the full
> regions
> always. This amounts to changing "garbage() > 0" to, say, "garbage()
> > 0 ||
> live() > 0".
> 
>  b) "aggressive" as product strategy (I can see how that can be
> useful to
> workaround late concmark starts at the expense of performance): in
> this mode, we
> can save quite a few cycles by not considering full regions for
> collection set.
> This amounts to changing "garbage() > 0" to handle the GCLAB waste.

Yes, I've been thinking about that too. 'Aggressive' might be a
misnomer and should probably be named 'testing' or such?

Roman