RFR: Initial sizing refactor [v2]

[Kelvin Nilsen]

On Wed, 21 Dec 2022 18:44:38 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve assertions and comments
>
> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.cpp line 235:
> 
>> 233:   }
>> 234: }
>> 235: 
> 
> I still question whether this is the right trigger for when to enlarge old-gen.  A properly running generational GC will spend nearly all its time doing young-gen and very little time doing old-gen.
> 
> The trigger for enlarging old-gen should be that we experience promotion failures (and/or that we identify at the end of init mark that we have more live data in aged regions than will fit in the current old-gen).
> 
> Old-gen collection triggers need to be refined when we are auto-sizing.  We can't use "percent free in old" or even "time to collect old > time to exhaust old", because we are trying to auto-tune to maintain that the percent free in old is very small.  We need a new way to trigger old-gen GCs.
> 
> Maybe, we trigger old-gen GC (rather than enlarging old-gen) if an old-gen enlargement request would cause us to exceed a target max-size for old-gen?
> 
> This doesn't have to be addressed in current PR.  But I'm just thinking that refinements of these heuristics may be necessary eventually.

Maybe the target max-size for old-gen is auto-tuned to, e.g., 10% larger than the maximum old-gen live memory following old-gen concurrent mark with some bias given to more recently observed measurements of old-gen live-memory.

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

PR: https://git.openjdk.org/shenandoah/pull/185