RFR: 8351464: Shenandoah: Hang on ShenandoahController::handle_alloc_failure when run test TestAllocHumongousFragment#generational

[William Kemper]

On Tue, 11 Mar 2025 23:28:32 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Not sure I want to change `ShenandoahControlThread.` It uses a different mechanism to track whether or not to notify. It only notifies when it services the alloc failure request (it doesn't depend on the shared `cancelled_gc` state the same way the generational mode does). In the scenario that leads to this live lock for the generational mode, the default mode would _not_ notify the waiters upon successful completion of the concurrent cycle. It would notify them after the subsequent degenerated cycle.
>
>> Not sure I want to change `ShenandoahControlThread.` It uses a different mechanism to track whether or not to notify. It only notifies when it services the alloc failure request (it doesn't depend on the shared `cancelled_gc` state the same way the generational mode does). In the scenario that leads to this live lock for the generational mode, the default mode would _not_ notify the waiters upon successful completion of the concurrent cycle. It would notify them after the subsequent degenerated cycle.
> 
> It does use the shared cancelled_cause, see the code here https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp#L68 and at [line 171](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp#L171), `ShenandoahControlThread` does have same problem, alloc_failure_pending is evaluated using shared cancelled_cause before starting a cycle.

@pengxiaolong , yes - I agree. Good catch.

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

PR Comment: https://git.openjdk.org/jdk/pull/23997#issuecomment-2715984419