RFR: 8377048: Shenandoah: shenandoahLock related improvments [v7]

[Xiaolong Peng]

On Wed, 25 Feb 2026 20:34:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert two more unnecessary changes for current pr
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2842:
> 
>> 2840:   ShenandoahFreeSet* free_set = ShenandoahHeap::heap()->free_set();
>> 2841:   // free_set is nullptr only at pre-initialized state
>> 2842:   assert(free_set == nullptr || !free_set->rebuild_lock()->owned_by_self(), "Dead lock, can't acquire heap lock while holding free-set rebuild lock");
> 
> Does Shenandoah really need its own parallel implementation of locks? `Mutex` handles lock acquisition ordering with ranking.

Yes, I agree that `Mutex` could handle the ranking issue more elegantly, but I don't think we could change the heap lock to use `Mutex` to replace spin lock in this PR, we could evaluate that after reducing the usage of heap lock, especially on the memory alloc code path. 

Meanwhile, if we want leverage the  ordering with ranking of `Mutex`, we will have to use `Mutex` for all the relevant locks(heap lock, free set rebuild lock..etc).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2855731027