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

[Xiaolong Peng]

On Tue, 2 Dec 2025 22:16: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 255 commits:
>> 
>>  - Add missing header for ShenandoahFreeSetPartitionId
>>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>>  - Fix a typo
>>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>>  - Port the fix of JDK-8372566
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>>  - Remove junk code
>>  - Remove unnecessary change and tidy up
>>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 100:
> 
>> 98: HeapWord* ShenandoahAllocator<ALLOC_PARTITION>::attempt_allocation(ShenandoahAllocRequest& req, bool& in_new_region) {
>> 99:   if (_alloc_region_count == 0u) {
>> 100:     ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint);
> 
> Looking for more comments here as well.  What does it mean that _alloc_region_count == 0?  Does this mean we have not yet initialized the directly allocatable regions (following a particular GC event)?  Or does it mean that we have depleted all of the available regions and we are out of memory? In the first case, it seems we would want to replenish our supply of directly allocatable regions while we hold the GC lock.  In the second case, it seems there's really no value in even attempting a slow allocation.  (If we were unable to refresh our directly allocatable regions, then it will not find allocatable memory even on the other side of the heap lock...)

I'll add comments on this, _alloc_region_count == 0 means we don't want to use any shared alloc region, it will also allocate with a heap lock, ideally the performance should be same as before, so it always simply find a region with enough space and allocate in the region.

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

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