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

[Kelvin Nilsen]

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

>> My mistake on first read here.  I see now that we only come into this function if fast-allocation failed.
>
> 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.

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

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