RFR: 8249787: Make TestGCLocker more resilient with concurrent GCs

[Erik Österlund]

Hi Roman,

Looks good.

Thanks,
/Erik

On 2020-07-23 12:44, Erik Österlund wrote:
> Hi,
>
> (I am sending this RFR on Roman's behalf. For some reason, he is 
> currently
> unable to send emails to hotspot-gc-dev. This is his email:)
>
> TestGCLocker seems to be made with the assumption that GCs are
> triggered on allocation failure. It has a somewhat complicated
> machinery to generate some GC pressure and especially to free up some
> memory in its artificial MemoryUser. This leads to some weird
> interactions with Shenandoah control machinery.
>
> For example, it frees memory when heap usage is >75% AND a certain time
> has passed since it last freed memory (500ms). In those 500ms, it will
> keep on allocating chunks of memory, eventually running OOM because it
> keeps holding on to those chunks, while the GC is running like mad
> trying to free up memory, but can't because the stupid up doesn't let
> go. However, it will still keep resetting timeSinceLastGC because of
> some tiny objects getting freed-up since last time (not enough to
> prevent OOM though).
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8249787
>
> Proposed solution is an option to pass-in minFreeCriticalWaitMS. This
> way we can let Shenandoah pass-in 0 and disable that check, which seems
> pointless anyway with a concurrent GC that might be triggered earlier
> than on allocation-failure.
>
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8249787/webrev.00/
>
> Testing: TestGCLockerWithShenandoah with various settings,
> hotspot_gc_shenandoah
>
> What do you think? Does it make sense?
>
> Thanks,
> Roman