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

[Kelvin Nilsen]

On Wed, 8 Oct 2025 18:13:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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.

Thanks for reminding me how this code works.  So removal of these lines of code has the effect of the following small change in behavior:

1. In the original code, if there was excess memory in old after computing the old (mixed) evacuation reserves (based on ShenandoahOldEvacWaste), we would dedicate this memory to the promotion budget to allow a few more objects to be promoted.  This excess memory is always less than a full region size.  Any excess larger than a region size is transferred to the mutator to reduce allocation pressure.

2. In the new code, any excess memory left in the old evacuation budget is simply left in the old evacuation budget.  By assigning this surplus memory to the old evacuation budget, we reduce the likelihood of experiencing an OOM during evacuation of old objects. This is because the reserve for old evacuation is even larger than what is specified by ShenandoahOldEvacWaste.

Where we place this excess memory is probably of little consequence since the amount of memory is always less than one region size.

However, I believe this will slow promotions during mixed evacuation cycles, which may partially explain why we're not seeing as many benefits from this PR as we had hoped for when we measure the impact on real workloads.

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

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