RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20]
Xiaolong Peng
xpeng at openjdk.org
Thu Jan 8 20:41:47 UTC 2026
On Tue, 6 Jan 2026 02:04:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits:
>>
>> - Merge branch 'openjdk:master' into cas-alloc-1
>> - Fix build error after merging from tip
>> - Merge branch 'master' into cas-alloc-1
>> - Merge branch 'master' into cas-alloc-1
>> - Some comments updates as suggested in PR review
>> - Fix build failure after merge
>> - Expend promoted from ShenandoahOldCollectorAllocator
>> - Merge branch 'master' into cas-alloc-1
>> - Address PR comments
>> - Merge branch 'openjdk:master' into cas-alloc-1
>> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 364:
>
>> 362: _free_set->partitions()->decrease_used(ALLOC_PARTITION, total_free_bytes);
>> 363: _free_set->partitions()->increase_region_counts(ALLOC_PARTITION, total_regions_to_unretire);
>> 364: accounting_updater._need_update = true;
>
> Here is where you know which tallies have been affected by this operation. This is where you should specialize the calls to freeset recompute_total_used() and recompute_total_affiliated(). Either call those from here, or add parameters to your accounting_updater object so that you do not have to overcompute each operation.
This is not the only place, there are many other places in the allocation code path as well, I can specialize the calls to recompute_total_used and recompute_total_affiliated in the places, but that will make the code necessary rambling, I'd rather to solve this issue and simplify it in https://bugs.openjdk.org/browse/JDK-8373371.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2673820942
More information about the hotspot-gc-dev
mailing list