RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks
Y. Srinivas Ramakrishna
ysr at openjdk.org
Wed Jan 21 20:44:51 UTC 2026
On Wed, 21 Jan 2026 18:26:38 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> 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.
Thanks, sorry for my confusion and my sloppy reading of the, ahem, minuend :-)
I'll reread more carefully and approve; the ranks now make sense of course.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29333#discussion_r2714270228
More information about the hotspot-gc-dev
mailing list