RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v4]
Kelvin Nilsen
kdnilsen at openjdk.org
Tue Oct 7 23:44:32 UTC 2025
On Tue, 7 Oct 2025 22:21:53 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 481:
>>
>>> 479: // promotions than fit in reserved memory, they will be deferred until a future GC pass.
>>> 480: size_t total_promotion_reserve = young_advance_promoted_reserve_used + excess_old;
>>> 481: old_generation->set_promoted_reserve(total_promotion_reserve);
>>
>> Can you clarify why we no longer need this set_promoted_reserve() call? (just in a PR comment probably, not necessarily a code comment.)
>
> 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?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2412176142
More information about the hotspot-gc-dev
mailing list