RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v3]

[Thomas Schatzl]

On Tue, 29 Jul 2025 20:45:36 GMT, Man Cao <manc at openjdk.org> wrote:

> As mentioned in the other comment, concurrent refinement threads typically consume very little CPU compared to concurrent mark workers, and most refinement threads are inactive most of the time. I think bloating up the divisor up to ConcRefinementThreads will undercount the wall-clock time "lost" by mutator threads due to concurrent GC.

What if there is significant concurrent refinement activity? That would unnecessarily expand the heap.

Running one of my go-to benchmarks (some "object storage"; you would not want to run it at that gc cpu usage level, i.e. 55% ;) ) gives the following thread times:

sun.threads.cpu_time.gc_conc_mark=       187537964718
sun.threads.cpu_time.gc_conc_refine=    1306781191282
sun.threads.cpu_time.gc_parallel_workers=561790592662
sun.threads.cpu_time.gc_service=            125919008

Not a very realistic scenario, still I would prefer to not discount refinement costs...

Maybe somehow separate marking and refinment cpu activity and merge again?

> For the other proposed approach using (concurrent-cpu-usage + gc-pause-cpu-usage) as dividend, it is much bigger change of behavior from the pause-time-based approach. I suspect it will suffer from the problem of fluctuating mutator CPU usage (https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14799278), due to using total-cpu-usage-during-mutator in divisor. Perhaps it is better to experiment separately from this PR?

It is a combination of both: for pauses use the existing approach, for mutator time it uses cpu usage.

However I agree that probably it suffers from the same issue, weighing cpu usage too much if the mutator is mostly idle, causing overexpansion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2242459016