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

[Xiaolong Peng]

On Tue, 6 Jan 2026 17:35:56 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 265 commits:
>> 
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Fix build error after merging from tip
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge branch 'master' into cas-alloc-1
>>  - Some comments updates as suggested in PR review
>>  - Fix build failure after merge
>>  - Expend promoted from ShenandoahOldCollectorAllocator
>>  - Merge branch 'master' into cas-alloc-1
>>  - Address PR comments
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 110:
> 
>> 108:   }
>> 109: 
>> 110:   uint dummy = 0;
> 
> Don't call this "dummy".  Call it regions_ready_for_refresh.  Remember the value and pass it in as a new argument to attempt_allocation_slow() so that we don't have to recompute it later.

The values from fast path won't be used anyway, that why I called it dummy. 
attempt_allocation_slow has to recompute it after acquiring heap lock. 
Imaging that have have two mutators, 8 shared alloc regions, both try to allocate the same time:
1. Both threads tried the fast path (attempt_allocation_in_alloc_regions) and failed, both see 8 alloc regions are ready to retire. 
2. Both threads will call into attempt_allocation_slow
3. The first thread acquired heap lock refresh all the 8 alloc regions and allocate in one of the region. the thread release heap lock,
4. The 2nd thread acquires heap lock successfully after 1st thread released it, now the regions_ready_for_refresh it saw in fast path is stale and has to be recomputed.

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

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