RFR: LRU/Generational should catchup with allocations happening after trigger

[Christine Flood]

Looks good to me.


Christine


On Tue, Aug 1, 2017 at 5:21 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> So I have been wondering why new partial heuristics miss so many new
> objects in pure allocation
> tests. Then it struck me that we have a window between the partial GC
> *trigger* detected by
> ShenandoahConcurrentThread, and the actual partial GC happening.
>
> If both are targeting the same percentage of young/old regions, that means
> some allocations will
> slip away! E.g. ShConcThread sees mutator allocated 400 MB, and our
> threshold is 400 MB, triggers
> the GC, but when GC finally hits, the application had managed to allocate
> another 50 MB, which will
> slip away.
>
> The solution appears to be polling the same "allocated" value the trigger
> used, and act based on
> that, which implicitly captures those allocations:
>   http://cr.openjdk.java.net/~shade/shenandoah/partial-catchup/webrev.01/
>
> See how beautiful the cycles are now in pure allocation workloads, they
> don't need any non-partial
> cycles to clean up anymore (these are from fastdebug builds, this is why
> two-digit pause times):
>
>   http://cr.openjdk.java.net/~shade/shenandoah/partial-
> catchup/generational-before.log
>   http://cr.openjdk.java.net/~shade/shenandoah/partial-
> catchup/generational-after.log
>
>   http://cr.openjdk.java.net/~shade/shenandoah/partial-
> catchup/lru-before.log
>   http://cr.openjdk.java.net/~shade/shenandoah/partial-
> catchup/lru-after.log
>
> It also improves testing time, because we don't have lots of floating
> garbage we need to verify with
> partial heuristics.
>
> Testing: hotspot_gc_shenandoah
>
> Thanks,
> -Aleksey
>
>