RFR: 8348595: GenShen: Fix generational free-memory no-progress check [v2]

[Kelvin Nilsen]

On Mon, 10 Feb 2025 22:24:35 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Interesting thoughts.  So young-generation size will change under these circumstances:
>> 
>> 1. There's a lot of young-gen memory to be promoted, or we choose to promote some young-gen regions in place (by relabeling the regions as OLD without evacuating their data).  In both of these cases, we may shrink young in order to expand old.
>> 2. The GC cycle is mixed, so it has the side effect of reclaiming some old regions.  These reclaimed old regions will typically be granted back to young, until such time as we need to expand old in order to hold results of promotion.
>> 
>> While it makes sense for expected to be computed based on "original size" of young generation, the question of how much free remaining in young represents "good progress" should probably be based on the current size of young.  Ultimately, we are trying to figure out if there's enough memory in young to make it worthwhile to attempt another concurrent GC cycle.
>> 
>> I realize this thinking is a bit "fuzzy".  The heuristic was originally designed for non-generational use.
>> 
>> I'm inclined to keep as is currently implemented, but should probably add a comment to explain why.  What do you think?
>
> Thanks for the explanation, I agree with it is bit "fuzzy".  
> I'm not sure we should consider following case:
> 
> Degen cycle doesn't reclaim any memory,  but promoted some young regions resulting in young capacity to shrink, in this case we may treat it as "good progress" but actually it is not.
> 
> A "good progress" could be `free_actual_after > free_actual_before && free_actual_after > free_expected`, what do you think? I am not sure all cases triggering degen cycle, this might be a false case that never happens.

If we manage to pass the test "free_actual_after > free_expected" following the degen, even if young has shrunk, I think it is reasonable to pursue concurrent GC.  Passing this exact test at the end of the next GC (assuming no further adjustments to generation sizes) would qualify us to continue with concurrent GC on the next cycle.

In general, it is very rare that "full gc" is the right thing to do.  we're in the process of deprecating it entirely.

I will add a comment to clarify the thinking here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23306#discussion_r1950040394