RFR: 8338534: GenShen: Handle alloc failure differently when immediate garbage is pending

[Y. Srinivas Ramakrishna]

On Fri, 30 Aug 2024 01:03:32 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Several changes are implemented here:
>> 
>> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
>> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
>> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.
>
> src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 104:
> 
>> 102:     _alloc_failure_gc.unset();
>> 103:     _humongous_alloc_failure_gc.unset();
>> 104:   }
> 
> For good hygiene, I'd move the variable value changes into the monitor which is held when waiting or notifying. I realize this doesn't matter for correctness, but makes debugging easier.
> 
> Further, if you protect the updates and reads of the variables with the lock, you don't need to do the extra atomic ops.
> 
> You'd need to examine all sets/gets and waits/notifys to make sure this works, but I am guessing it will, and it'll also improve performance.
> 
> However, that can be done in a separate effort, if you prefer, for which I'm happy to file a separate ticket for that investigation/change.

I realize now that this idiom is quite pervasive in Shenandoah code, so just fixing this instance of it doesn't accomplish much at this time. I am not convinced it's a good idiom. I'll investigate this separately. I vaguely recall a discussion along these lines in an older PR.

I'll file a separate ticket for this; you can ignore this remark for the purposes of this PR.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737594870