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

[Y. Srinivas Ramakrishna]

On Tue, 20 Jan 2026 20:47:24 GMT, William Kemper <wkemper 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?

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

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