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

[William Kemper]

On Tue, 24 Feb 2026 18:05:48 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. 
>> 
>> Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker.
>> 
>> Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel
>> 
>> ### Test
>> - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah
>> - [x] GHA
>
> 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.

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

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