RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration

William Kemper wkemper at openjdk.org
Fri Oct 31 01:15:09 UTC 2025


On Wed, 29 Oct 2025 05:29:14 GMT, Xiaolong Peng <xpeng 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?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 901:

> 899:   }
> 900: 
> 901:   bool allow_new_region = can_allocate_in_new_region(req);

Are we losing the check here? Before this change, the region had to be `FREE` _and_ the generation affiliated with the request had to have `free_unaffiliated_regions`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2479902404
PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2479900571


More information about the hotspot-gc-dev mailing list