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

[Xiaolong Peng]

On Wed, 7 Jan 2026 22:54:13 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> I will update the PR and not use atomic version here, and also another place in refresh_alloc_regions. 
>> 
>> Having volatile_top and nonvolatile_top seems necessary, it will make the code more complicated w/o much performance benefits, with CAS allocator, most of alloc request will be handled by the atomic code path, in only few 
>> cases we need non-atomic allocation:
>> * After reserving alloc regions from free set before storing to alloc region, it performs obj allocation if the alloc request has not been satisfied yet. 
>> * After trying atomic allocation, refresh alloc regions fails, it will try to find a region in free set with enough space for the allocation request.
>> 
>> Yes, all the _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs are volatile now, out of these fields, I believe I can maybe remove volatile for _age and _youth(?), but the update of the rest must be atomic because mutators will increase the values in the CAS allocation code path w/o heap lock.
>
> I have updated the method `atomic_allocate_in` with a template parameter IS_SHARED_ALLOC_REGION, now only when allocating from shared alloc regions the IS_SHARED_ALLOC_REGION parameter is set to true to use atomic operations.

I have updated the code to use _volatile_top for CAS allocation, and keep _top nonvolatile, this addresses your concern about the race condition between threads doing CAS allocation and the thread trying to refresh alloc regions, thanks for the suggestion!

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

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