RFR: 8373819: GenShen: Requested generation may be null [v4]

[William Kemper]

On Fri, 9 Jan 2026 23:08:11 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash
>>  - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash
>>  - Fix typo in assertion message
>>  - Take regulator thread out of STS before requesting GC
>>    
>>    The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other.
>>  - Add comments
>>  - Revert back to what should be on this branch
>>  - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash
>>  - Don't know how this file got deleted
>>  - Carry over gc cancellation to gc request
>>  - Do not let allocation failure requests be overwritten by other requests
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 721:
> 
>> 719: }
>> 720: 
>> 721: void ShenandoahGenerationalControlThread::notify_control_thread(GCCause::Cause cause) {
> 
> Apropos my comment above, this code has a bad smell that some versions of the method expect the lock to be held, and other methods acquire the lock.
> 
> It makes reasoning about the code at an abstract level very error-prone, and potentially difficult to maintain correctly over time.

The overload that does the actual work always requires the lock to be held. The other overload is a convenience method that takes the lock and provides the locker to the actual method that does the work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2683485267