RFR: Initial sizing refactor [v2]

[Kelvin Nilsen]

On Tue, 20 Dec 2022 20:12:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Some things to highlight here:
>> * This change borrows a bit of code from G1 to handle processing of command line arguments used to size the young generation.
>> * A (hard coded for now) threshold on the difference between young/old time has been added to reduce resizing churn.
>> * The adaptive heuristic doesn't consider the `soft_tail` anymore. `available` is already adjusted for the soft max capacity.
>> * `SoftMaxHeapSize` is used to compute the soft max size and max size for the young generation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve assertions and comments

Marked as reviewed by kdnilsen (Committer).

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.

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

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