RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v5]
William Kemper
wkemper at openjdk.org
Thu Oct 16 18:38:54 UTC 2025
On Tue, 14 Oct 2025 17:50:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> 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.
This part of the algorithm didn't really change. During a mixed evacuation, it attempts to restrict old evacuations to _empty_ regions. The difference between the old reserve and the memory available in empty regions is made available for promotions. I believe the sum of the memory available in these non-empty old regions could be more than a single region. Anything not expected to be used by old evacuations or promotions is returned to the mutator's partition. Before this change, the value of _expected promotions_ was computed as `tenurable region count * region size * promo waste`. After this change, the value of _expected promotions_ is computed directly from the census during mark. It is generally the case that expected promotions _before_ this change will be less than expected promotions _after_ this change. Excess old reserve is still transferred to the mutator partition, but it will generally be less now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2437060757
More information about the shenandoah-dev
mailing list