RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration
Xiaolong Peng
xpeng at openjdk.org
Fri Oct 31 15:36:54 UTC 2025
On Fri, 31 Oct 2025 01:12:19 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
>> 1. fast path: traverse regions between left most and right most in the partition, and try to allocate in an affiliated region in the partition;
>> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.
>>
>> 2 can be saved if we also remember the first FREE region seem in 1.
>>
>> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference)
>>
>>
>> Test:
>> - [x] hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 779:
>
>> 777: return result;
>> 778: }
>> 779: } else if (free_region == nullptr && r->affiliation() == FREE &&
>
> The logic in `can_allocate_from` is slightly different from what's here. Do we want to check that the region is `FREE` _or_ it is `trash` and we are not in concurrent weak roots?
`try_allocate_in(free_region, req, in_new_region)` returns nullptr if the region is trash and we are in in concurrent weak roots, I added the additional check to ensure try_allocate_in always succeed. The check may not be needed, I remember a FREE region can't be trash, I updated the trash/recycle related code in a while ago, I will double check.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2481827416
More information about the hotspot-gc-dev
mailing list