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

[Kelvin Nilsen]

On Sat, 8 Feb 2025 02:06:13 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Thanks for this suggestion.  I've made change.  It turns out there was actually a bug in the original implementation, so I am retesting the performance results.
>
> Thanks, honest I didn't understand that why `(free_set->capacity() + free_set->reserved()` represents capacity of young in generational, is it the bug you found? `free_set->capacity()` is the capacity of all mutator regions which also excludes the regions doesn't have capacity for new object alloc(it is calculated when rebuild free set)
> 
> I thought a bit more, it makes more sense to calculate free_expected in `snap_before`, max_capacity of generations may change after collection, the free_expected should be calculated before the cycle.

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?

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

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