RFR: 8373819: GenShen: Requested generation may be null [v4]
William Kemper
wkemper at openjdk.org
Mon Jan 12 19:09:24 UTC 2026
On Sat, 10 Jan 2026 00:07:54 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> 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.)
> Will they "observe the shutdown" if mode isn't "stopped"?
Yes, gc waiters are waiting to observe an increment in the GC ID. Alloc failure waiters are waiting for `ShHeap::_cancelled_cause` to stop being an allocation failure. Both groups of waiters will exit their loop if the control thread itself should terminate. Only the regulator thread waits on `gc_mode`. Changing the `gc_mode` is always done when the `_control_lock` is held and will notify any waiters.
The regulator thread does read the `gc_mode` without a lock, but only for deciding when to evaluate heuristic triggers. The regulator thread does take the lock and reads `gc_mode` again before making a request to start a GC cycle.
> the "mode" parameter used in the non-generational control thread is completely internal to the control thread
This is one of the major differences with the non-generational mode. In the non-generational mode, the control thread is responsible for running the collection cycle _and deciding when to start a cycle_. In the non-generational mode, the control thread cannot evaluation heuristics when it is running a cycle (indeed, it would make no sense to because a cycle is already running). However, in the generational mode, these responsibilities are decoupled because we want to continue evaluating heuristics while the control thread is running an old mark. This is how we decide to interrupt an old cycle and start a young cycle. The `gc_mode` is exposed to the regulator thread so that it does not futilely evaluate heuristics when the control thread is running a young or global cycle.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2683533455
More information about the shenandoah-dev
mailing list