RFR: Initial sizing refactor [v2]

[William Kemper]

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

>> 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.

I agree we can wire up more signals to the resizing mechanism. In the scenario you describe, where old generation has become _too small_ and old collections are running _too frequently_, the MMU based resizing would enlarge the old generation.

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

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