RFR: 8349094: GenShen: Race between control and regulator threads may violate assertions [v12]

[Y. Srinivas Ramakrishna]

On Mon, 24 Feb 2025 17:50:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 64:
>> 
>>> 62: private:
>>> 63:   // This lock is used to coordinate setting the _requested_gc_cause, _requested generation
>>> 64:   // and _gc_mode. It is important that these be changed together and have a consistent view.
>> 
>> In that case, for ease of maintenance, I'd move the declaration of all of the 3 data members that this lock protects next to this lock, either immediately preceding or immediately succeeding its declaration in the body of this class.
>> 
>> Are these data members always both read and written under this lock? If so, then `_gc_mode` below doesn't need to be defined `volatile`.
>
> The `_gc_mode` is read without the lock by the regulator thread. However, the regulator thread does take the lock and reads `_gc_mode` again under the lock before making any state changes.

Make sense -- so the regulator uses a double-checked locking idiom. May be note that somewhere where you talk about this lock and the volatile _gc_mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23475#discussion_r1970654476