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

Xiaolong Peng xpeng at openjdk.org
Mon Sep 22 08:46:43 UTC 2025


On Thu, 10 Jul 2025 22:34:27 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282:
>> 
>>> 280: 
>>> 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) {
>>> 282:   shenandoah_assert_heaplocked();
>> 
>> Are you now calling this directly from the CAS allocators?  So you want to not have to assert heap locked and that is why we make the used accounting atomic?
>> 
>> My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable.
>
> Yes, we increase used after CAS allocation, so it can be called w/o lock.
> 
> I'll revisit it along with the the comments you have above, if we count the entire region as used when we reserve a region for direct allocation, this change can be removed.

I have changed it to the approach as you suggested, now it count the entire region as used at the time the region becomes directly allocatable.

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151:
>> 
>>> 2149: 
>>> 2150: template<bool IS_TLAB>
>>> 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) {
>> 
>> Not clear to me what prefix par_ represents.  Parallel allocate (without lock?)
>
> Yes.
> The name is a bit confusing, what about `try_allocate_single_for_mutator`?

Technically not completely without lock, it may take lock when there is need to retire and refill new directly allocatable regions.

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

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


More information about the hotspot-gc-dev mailing list