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

[Y. Srinivas Ramakrishna]

On Sat, 10 Jan 2026 00:00:46 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 95:
>> 
>>> 93:   notify_gc_waiters();
>>> 94:   notify_alloc_failure_waiters();
>>> 95:   set_gc_mode(stopped);
>> 
>> Will they "observe the shutdown" if mode isn't "stopped"? Should line 95 move before line 93? Also is `gc_mode`'s state transitions protected in any manner, so they are consistent with any other observable state from the standpoint of threads that may interact with the controller? I see for example that the RegulatorThread looks at the controller thread's gc_mode to make certain GC triggering decisions, but it doesn't look like the reading of the mode and the requesting of a GC are protected by a lock that prevents races/glitches. In general such interactions lead to an increase in the state-space of interactions that the parties need to deal with correctly.
>
> The reason I am leaving this comment here is that further above (lines 85-88), and in many of the other mode changes we seem to take care to use the control lock to protect these transitions so that other parties may observe the right state. Perhaps that is not needed in some cases, but the plurality of different forms of update of state that is modifed and may be read by other threads in conjunction with other state leaves me feeling queasy about the possible cracks in the coordination surface that may open us up to trouble.

(Note that the "mode" parameter used in the non-generational control thread is completely internal to the control thread and unlike in the case of the generational control thread here, never leaks out of that thread to be consulted by another thread asynchronously.)

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

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