RFR: 8377048: Shenandoah: shenandoahLock related improvments
Xiaolong Peng
xpeng at openjdk.org
Tue Feb 3 18:41:15 UTC 2026
On Tue, 3 Feb 2026 17:28:14 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/shenandoahFreeSet.cpp line 912:
>
>> 910: void ShenandoahRegionPartitions::assert_bounds() {
>> 911: shenandoah_assert_heaplocked();
>> 912: ShenandoahRebuildLocker locker(_free_set->rebuild_lock());
>
> assert_bounds() often happens when we are not rebuilding the free set. Not clear why you need to add this lock here.
For this change, it is not needed, I peel the PR from the change to defer heap usage accounting re-computation in which the same lock is used for when update&read heap usage accounting data, this one is untented, I'll remove it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760474019
More information about the shenandoah-dev
mailing list