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

[Kelvin Nilsen]

On Tue, 2 Dec 2025 22:00:17 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 80:
> 
>> 78:           break;
>> 79:         case ShenandoahFreeSetPartitionId::OldCollector:
>> 80:           _free_set->recompute_total_used</* UsedByMutatorChanged */ true,
> 
> These parameters seem overly conservative.  Can we distinguish what needs to be recomputed?
> Normally, OldCollector allocation does not change UsedByMutator or UsedByCollector.  It will only change MutatorEmpties if we did flip_to_old.  It will normally not changed OldCollectorEmpties (unless it flips multiple mutator to OldCollector.  if might flip one region from mutator, but that region will not be empty after we allocate fro it...

I suppose we could use conservative values for a first implementation, as long as we file a "low priority" ticket to come back and revisit for improved efficiency at a later time.

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

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