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

[Kelvin Nilsen]

On Tue, 6 Jan 2026 18:13:09 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 114:
> 
>> 112:   HeapWord* obj = attempt_allocation_in_alloc_regions(req, in_new_region, alloc_start_index(), dummy);
>> 113:   if (obj != nullptr) {
>> 114:     return obj;
> 
> Even in the case that we successfully fill our allocation request, if regions_ready_for_refresh is greater than some percentage of _alloc_region_count (e.g. > _alloc_region_count / 4), then we should grab the heap lock and refresh_alloc_regions() here.  Otherwise, we will gradually degrade the number of directly_allocatable_regions until we are down to one before we refresh any of them.

After further thought, am thinking the threshold for refresh_alloc_regions() might be if (regions_ready_for_refresh >= _alloc_region_count / 2).  That would reduce the number of slow paths through the allocator.  If we can re-randomize the thread-local start indexes when their original start index hits a retire-able region, this might work ok.

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

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