RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v4]

[William Kemper]

On Tue, 7 Oct 2025 23:41:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In `compute_evacuation_reserves` we are setting the promotion reserve to the maximum possible to handle everything tenurable this cycle (this is still capped by the maximum evacuation reserve for old). I was reluctant to scale the promotion reserve by `ShenandoahPromoEvacWaste`  for fear it would over commit the collector's reserves and lead to OOM errors during evacuation.
>
> So in the new design, we have full awareness of all promotable objects, and we've already done our best to budget for those.  So there's no such thing as "unanticipated promotions".
> 
> Separate question is whether we scale promotion reserve by ShenandoahPromoEvacWaste.  So if old is larger than necessary to handle the anticipated mixed evacuations and promotions, the new code is essentially saying "use this extra space for mixed evacuations rather than for promotions".   Since we're not expanding the promoted_reserve, promotions will not be allowed to touch it.
> 
> Am I understanding the intent correctly?

In `compute_evacuation_budgets`, if there are mixed collection candidates we set the initial promotion reserve to zero and the old evacuation reserve to the maximum. However, we then restrict old evacuation reserve to only empty regions. The difference between `old available` and `old unaffiliated` is given to the promotion reserve. Here again, I didn't want to scale the promotion reserve because it's basically the scraps of the old generation and I worry about over committing the old reserve. When there are no mixed collections, we use the entirety of old for promotions. Any old regions not needed for old evacuations or promotions are transferred to the young generation as they were before this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2414656521