Reserved space in GC/TLABs

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

Thanks,
-Aleksey