RFR: 8357471: GenShen: Share collector reserves between young and old [v2]

Kelvin Nilsen kdnilsen at openjdk.org
Mon Nov 10 15:55:12 UTC 2025


On Sat, 31 May 2025 02:53:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - respond to reviewer feedback
>>  - Keep gc cycle times with heuristics for the relevant generation
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 183:
> 
>> 181:   }
>> 182: 
>> 183:   heap->young_generation()->set_evacuation_reserve((size_t) (young_evac_bytes * ShenandoahEvacWaste));
> 
> So we are using the amount to be evacuated out of young (suitably marked up to account for waste) from the collection set of a specific cycle to predict the same for the next cycle? And similarly for the promotion bytes.
> 
> This seems reasonable, but how does that compare with using the live data identified in the most recent marking cycle instead? I can imagine that the former is more accurate under steady state assumptions and the latter is an overestimate to the extent that not all live data will be evacuated because it's in mostly live, i.e. densely live regions. However, it would be interesting to see how they compare and which tracks reality better. Since this is in the nature of a prediction/estimate, once can consider a control algorithm that tries to move the estimate closer based on minimizing some historical deviation between marked vs evacuated.
> 
> This need not be done here, but can be considered a future enhancement/experiment.

These reserves are applied to the current cycle, as we are about to begin evacuation and we need to know how much memory will be consumed in old and young during this cycle.  The promo budget helps assure that overly aggressive promotions do not cause mixed evacuations to fail (by consuming memory that should have been set aside to hold the mixed evacuations).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2511095501


More information about the hotspot-gc-dev mailing list