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

[Xiaolong Peng]

On Tue, 6 Jan 2026 18:09:05 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 133:
> 
>> 131:   ShenandoahHeapAccountingUpdater accounting_updater(_free_set, ALLOC_PARTITION);
>> 132: 
>> 133:   if (regions_ready_for_refresh > 0u) {
> 
> Since we've already taken the heap lock because we failed to allocate "fast", I'm ok to go ahead and refresh any regions that are ready right now, even if it's only 1 region.
> 
> I'm wondering if we can avoid thrashing in the case that there are no more regions available.  We might want to keep a state variable that represents whether there exist free-set regions with which to refresh our cache.  This could be updated whenever we "add to" or "rebuild" the free set, and whenever refresh_alloc_regions() find there is insufficient supply to demand.  We would want to avoid repeated calls to refresh_alloc_regions() if there are no "refresh_regions_available".

To actually track the accurate number of `refresh_regions_available`, we need to add three counters: one for each partition. Since we always retire the region is the free is less than PLAB::min_size(), we may already have it in free set partitions(_region_counts?).

There is also complexity here, for Collector and OldCollector, we allow them to transfer regions from Mutator partition,  we have to consider FREE regions in mutator partition to calculate  "refresh_regions_available" for Collector/OldCollector.

It should be rare case when the entire heap is almost filled up, I am wondering how much benefit we could get from doing that, if you are ok with it I'd suggest to consider this optimization later.

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

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