RFR: Use timed wait to sleep control thread

[Aleksey Shipilev]

On Tue, 6 Apr 2021 18:44:02 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

Oh wait, questions...

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

> 372:       // The timed wait is necessary because this thread has a responsibility to send
> 373:       // 'alloc_words' to the pacer when it does not perform a GC.
> 374:       MonitorLocker lock(&_control_lock, Mutex::SafepointCheckFlag::_no_safepoint_check_flag);

This is just `Mutex::_no_safepoint_check_flag`, Hotspot uses that everywhere. Another instance in also in the same file.

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

> 766:     _gc_requested.set();
> 767:     _requested_gc_cause = cause;
> 768:     notify_control_thread();

So this thing holds `_gc_waiters_lock`. I noticed it when trying to implement JDK-8264851. Fastdebug builds would fail with: `#  assert(false) failed: Attempting to acquire lock ShenandoahControlWaitGC_lock/11 out of order with lock ShenandoahRequestedGC_lock/11 -- possible deadlock`. How is that handled here?

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

PR: https://git.openjdk.java.net/shenandoah/pull/28