RFR: 8325670: GenShen: Allow old to expand at end of each GC
Y. Srinivas Ramakrishna
ysr at openjdk.org
Mon Feb 19 20:54:10 UTC 2024
On Mon, 19 Feb 2024 17:41:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> If you feel more comfortable, I can put the MIN2 expression into the normal case handling. But I'll be wanting to take it out in the upcoming complementary PR.
>
> Context: xfer_limit will be zero if there is no "planned" GC idle time. The allocation runway goes to zero if we have experienced recent degens and/or full GCs, because penalties accumulate which cause us to immediately trigger young GCs.
I am beginning to better understand what you were trying to achieve, but I am still not quite there.
Is there a natural sensible limit at which `max_old_reserve` can be bounded? It would seem then that, since you were not previously bounding the computation of `max_old_reserve` in any manner and you don't want to bound it to `old_available + xfer_limit`, that a more natural and essentially largest possible value would be the sum of what young can promote and what old can evacuate, which would look something like `heap->max_capacity()`, since it would effectively be morally equivalent to imposing no limits on `max_old_reserve`.
Alternatively, if you are considering changing this whole thing anyway, perhaps we just do that directly. If you expect that PR to take a while and you just want to restore old behaviour, I'd suggest bounding the calculation of `max_old_reserve` to `heap->max_capacity()`, since that is a natural limit irrespective of what SOERP happens to be (and not artificial and confusing like the one that you suggested covering that one case of SOERP sending the value to NaN but not otherwise bounding it and allowing it to grow arbitrarily large and wrapping around).
Let me know if that makes sense.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/394#discussion_r1495004950
More information about the shenandoah-dev
mailing list