RFR: 8377048: Shenandoah: shenandoahLock related improvments

[Xiaolong Peng]

On Tue, 3 Feb 2026 17:43:56 GMT, Kelvin Nilsen <kdnilsen 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, use ShenandoahReentrantLock for ShenandoahRebuildLock.
>> 
>> 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
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 121:
> 
>> 119: 
>> 120: typedef ShenandoahLock                       ShenandoahHeapLock;
>> 121: // ShenandoahHeapLocker checks potential deadlock and asserts
> 
> Years from now, the reader of this comment will not "appreciate" the context in which it was written.  The comment only makes sense in the context of this "diff".
> 
> Would be better to say: ShenandoahHeapLocker implements a lock to assure mutually exclusive access to the global heap data structures.  Asserts in the implementation detect potential deadlock usage with regards the rebuild lock that is present in ShenandoahFreeSet.  Whenever both locks are acquired, this lock should be acquired before the ShenandoahFreeSet rebuild lock.

Thanks, appreciate it! I'll update the comments here.

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

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