RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5]

Xiaolong Peng xpeng at openjdk.org
Tue Dec 2 18:40:21 UTC 2025


On Wed, 5 Nov 2025 20:31:18 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits:
>> 
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - format
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Merge branch 'master' into cas-alloc-1
>>  - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Fix errors caused by renaming ofAtomic to AtomicAccess
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 271:
> 
>> 269:     _used[int(which_partition)] = value;
>> 270:     _available[int(which_partition)] = _capacity[int(which_partition)] - value;
>> 271:     AtomicAccess::store(_used + int(which_partition), value);
> 
> Also here, should not require AtomicAccess.

Sorry, it is junk code left over, I'm tidying up the changes in the PR, this line will be removed.

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 363:
> 
>> 361: }
>> 362: 
>> 363: void ShenandoahHeapRegion::reset_alloc_metadata() {
> 
> Do we need to make these atomic because we now increment asynchronously from within mutator CAS allocations?  Before, they were only adjusted while holding heap lock?  I'm wondering if add-with-fetch() or CAS() would be more/less efficient than AtomicAccess::stores.  Can we test the tradeoffs?

Yes, we need to update these from mutator after every allocation w/o heap lock.

`reset_alloc_metadata` it to reset the values, we have to use AtomicAccess::store, it is not in the hot path, it is only invoked when the region is recycled, I don't think there is performance issue here.

For the code in hot path of mem allocation, I simply use `AtomicAccess::add` with `memory_order_relaxed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2562099016
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2562086131


More information about the shenandoah-dev mailing list