RFR: 8249787: Make TestGCLocker more resilient with concurrent GCs

[Roman Kennke]

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