RFR: 8373100: Genshen: Control thread can miss allocation failure notification [v2]

[William Kemper]

On Fri, 12 Dec 2025 23:57:50 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set requested gc cause under a lock when allocation fails
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 143:
> 
>> 141:   void notify_control_thread(MonitorLocker& ml, GCCause::Cause cause, ShenandoahGeneration* generation);
>> 142:   void notify_control_thread(GCCause::Cause cause);
>> 143:   void notify_control_thread(MonitorLocker& ml, GCCause::Cause cause);
> 
> Nit:
> 
> I'd (subjectively) order them thus: (nct = notify_control_thread)
> 
> 1. nct(cause)
> 2. nct(ml, cause)
> 3. nct(cause, generation)
> 4. nct(ml, cause, generation)
> 
> For completeness in the documentation comment preceding, state that if an argument, cause or generation, is missing, it isn't updated.
> 
> I am assuming that there is a specific small subset of cause values where the generation isn't important to spell out and really implies "isn't necessary or is implicitly understood" for cancellation/request cause? Is there a call argument/consistency check that might be done in the nct:s where these bottom out to confirm this, or am I being unnecessarily paranoid?

Yes, there are two uses where we don't need the generation:
* It's important to _not_ update the generation for an allocation failure (degenerated cycle needs to use same generation)
* We are shutting down the JVM and don't want to start another cycle.

All cases need to pass a `GCCause`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2615896228