RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks

[William Kemper]

On Wed, 21 Jan 2026 02:10:14 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Reduce the rank of `safepoint` locks and rename them to avoid confusion with `nosafepoint` ranked locks.
>
> src/hotspot/share/gc/shenandoah/shenandoahController.hpp line 47:
> 
>> 45:   const Mutex::Rank WAITERS_LOCK_RANK = Mutex::safepoint - 5;
>> 46:   const Mutex::Rank CONTROL_LOCK_RANK = Mutex::nosafepoint - 2;
>> 47: 
> 
> I see code where we lock gc waiters lock then proceed to take control lock, e.g.
> 
> https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L767
> 
> which calls:
> 
> https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L703
> 
> Wouldn't that mean we should rank the latter lower than the former?
> 
> May be I am confusing myself on the direction of locking rank. I thought that we can only take locks in reducing order of rank (so   can't take (safepoint - 2) while holding (safepoint - 5))?
> 
> https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/runtime/mutex.cpp#L452
> 
> Can you run all of the jtreg tests to see if we are safe across all paths, or if locks need reranking?

You are correct on all accounts here, except the basis for control lock is `Mutex::nosafepoint` and the basis for the waiter's locks is `Mutex::safepoint`. `safepoint` is defined as `nosafepoint + 20` so `nosafepoint` _is_ lower.  I didn't actually change the rank of the control lock, just pulled it into a shared constant as both `ShControlThread` and `ShGenerationalControlThread` share the value. This branch passed GHA and internal testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29333#discussion_r2713824630