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

[Xiaolong Peng]

On Fri, 9 Jan 2026 19:24:44 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 376:
>> 
>>> 374: }
>>> 375: 
>>> 376: THREAD_LOCAL uint ShenandoahMutatorAllocator::_alloc_start_index = UINT_MAX;
>> 
>> I raised questions about this in a previous review.  Have I overlooked your response?  What is the tradeoff between declaring this THREAD_LOCAL vs. creating a new field in ShenandoahThreadLocal?  I believe we need to use fields of ShenandoahThreadLocal so that we do not incur an overhead on all threads when JVM is not configured for Shenandoah GC.
>
> I don't have concern to move it to ShenandoahThreadLocalData, the benefit of using THREAD_LOCAL is just better cohesive code because  _alloc_start_index is defined in the same namespace where it is used. Performance wise, I don't think there is much benefits.
> 
> I do see ZGC also use THREAD_LOCAL directly, I guess the overhead on all threads is not a huge concern. 
> But given Shenandoah has ShenandoahThreadLocalData to manage all the thread locals, it make sense to not use THREAD_LOCAL directly, I'll update the PR to move _alloc_start_index to ShenandoahThreadLocalData.

While I am trying to use ShenandoahThreadLocalData, I realized that I need to add 2 alloc start index, one for ShenandoahMutatorAllocator, one for ShenandoahCollectorAllocator. Later when I update ShenandoahOldCollectorAllocator to use CAS allocation, one more will be added.

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

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