RFR: Initial sizing refactor [v2]

[Y. Srinivas Ramakrishna]

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

src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.cpp line 222:

> 220:   log_info(gc)("Thread Usr+Sys YOUNG = %.3f, OLD = %.3f, GLOBAL = %.3f", young_time_s, old_time_s, global_time_s);
> 221: 
> 222:   if (abs(delta) <= transfer_threshold) {

I thought the original idea was to use the difference in MMU's for old and young as the error signal to drive the (direction of the) transfer, rather than the difference in the actual times? Am I misinterpreting what `reset_collection_time` returns? You do refer to it as `thread utilization` (akin to MMU) in the log message below.

src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.hpp line 57:

> 55:   // Returns true if the young generation is configured to enqueue old
> 56:   // oops for the old generation mark queues.
> 57:   bool is_bootstrap_cycle() {

Why is this called a `bootstrap cycle`? I must be missing some big picture background of nomenclature here.

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

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