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

[Xiaolong Peng]

On Tue, 6 Jan 2026 22:37:02 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 192:
> 
>> 190:   uint i = alloc_start_index;
>> 191:   do {
>> 192:     if (ShenandoahHeapRegion* r =  nullptr; (r = _alloc_regions[i].address) != nullptr && r->is_active_alloc_region()) {
> 
> Note that there is a race (and performance overhead) with checking r->is_active_alloc_region().  Though a region might be active when we check it here, it may be inactive by the time we attempt to atomic_allocate_in().
> 
> This is one reason I prefer to use "volatile_top == end" to denote !is_active_alloc_region.  This way, you only have to check once (rather than checking is_active() and then checking has_available()).  And there is no race between when you check and when you attempt to allocate.

I have updated the code to use volatile_top in fast path to allocate from shared alloc regions, it won't test is_active_alloc_region any more, as you suggested, volatile_top is set to the end of region if is it not an active alloc region.

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

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