RFR: 8254623: gc/g1/TestHumongousConcurrentStartUndo.java still fails sometimes

[Kim Barrett]

> On Oct 13, 2020, at 10:25 AM, Thomas Schatzl <tschatzl at openjdk.java.net> wrote:
> 
> Hi all,
> 
>  can I have reviews for this change of the gc/g1/TestHumongousConcurrentStartUndo.java test to make it even more
>  resilient to timing?
> 
> Previously the test tried to create a stable initial condition by performing a full gc before that test step, but the
> problem is about when the first concurrent mark happens while building up the large set of humongous object kept alive:
> if it happens too early, and the concurrent undo operation takes too long, the next concurrent start will just be
> another undo because the large set of humongous objects will already be unreferenced and may as well cause a concurrent
> undo and not a concurrent mark.
> 
> The solution I came up with is that *after* creating all the humongous objects of the large set trigger an extra
> concurrent mark (and wait for its completion). That one (or some before) must have been a concurrent mark because at
> least at that point the heap must have been occupied by more than the IHOP value.

Rather than heuristic methods for controlling whether and when concurrent cycles start/run,
have you considered using the concurrent gc breakpoint mechanism to take explicit control?
WhiteBox provides API wrappers for the user-side functions in gc/shared/concurrentGCBreakpoints.hpp
(which has more detailed documentation than WhiteBox).