RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests

[Aleksey Shipilev]

On Fri, 8 Oct 2021 16:47:07 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I were able to reproduce with aggressive heuristics. 
> 
> A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set.
> 
> The solution is only run breakpoints during _wb_breakpoint GC.
> 
> Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause.
> 
> Test:
> 
> - [x] tier1 with Shenandoah

Looks good with minor nits.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 54:

> 52: class ShenandoahBreakpointGCScope : public StackObj {
> 53: private:
> 54:   GCCause::Cause _cause;

Better be `const`?

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 72:

> 70: class ShenandoahBreakpointMarkScope : public StackObj {
> 71: private:
> 72:   GCCause::Cause _cause;

Also `const`?

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 509:

> 507:   while (current_gc_id < required_gc_id) {
> 508:     _requested_gc_cause = cause;
> 509:     _gc_requested.set();

Ah. This whole thing is under _gc_waiters_lock. But there is a raw read of `_requested_gc_cause` and `_gc_requested` in `ShenandoahControlThread::run_service`. Pity. Could you please fork it out as separate (more backportable) bug?

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5868