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

[Xiaolong Peng]

On Tue, 6 Jan 2026 17:34:06 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> But part of the reason for my confusion is that you are trying to do fast allocations while holding the heap lock!
>> 
>> The reason we came into attempt_allocation_slow() is because we already failed to attempt_allocation_in_alloc_regions().  There's no need to call this a second time.  You should have remembered regions_ready_for_refresh and passed this in as an argument to attempt_allocation_slow().
>
> I'm not concerned that the count of regions_ready_for_refresh might be stale.  If this count is getting incremented "during" our allocation, we will see this result soon enough.  If multiple mutators fail fast-path allocation simultaneously, they will each acquire heap lock either way (existing implementation vs. new implementation that does not retry the allocation).  Acquiring the heap lock is the "expensive" operation.  If the first one refreshes allocation regions, then subsequent invocations will not find any regions to be refreshed.

The concern is the not "this count is getting incremented "during" our allocation", it is the the case when it get decremented because other mutators may have already refreshed all alloc regions before current mutator getting heap lock, we have call attempt_allocation_in_alloc_regions again after successfully acquiring heap lock because of this.

Same design can be also found in G1, Parallel and Serial GC's CAS allocator.

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

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