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