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

Man Cao manc at openjdk.org
Tue Jul 29 20:47:56 UTC 2025


On Mon, 28 Jul 2025 11:26:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Fwiw, G1 has both `ConcGCThreads` (for marking; 1/4th of `ParallelGCThreads`) and `ConcRefinementThreads` (for refinement; equal in count with `ParallelGCThreads`) which are active at the same time.
>> Not sure if only using `ConcGCThreads` (`ParallelGCThreads`?) is appropriate for this calculation.
>
> An alternative would be to consider concurrent cpu usage (`concurrent-cpu-usage`) as fraction of total cpu usage during the mutator phase (`total-cpu-usage-during-mutator`), and consider gc pause cpu usage as 100% total cpu usage during the pause (where `gc-pause-cpu-usage = #active processors * pause-duration`).
> 
> Ie. in total
> 
>   gc-time-ratio = (concurrent-cpu-usage + gc-pause-cpu-usage) / (total-cpu-usage-during-mutator + gc-pause-cpu-usage)
> 
> The dividend is G1 total cpu usage from end of previous GC to end of next GC, the divisor total cpu usage during the same time frame.
> 
> 
> It may be a bit problematic wrt to changing active processors but it seems preferable to guessing the number of threads used.

> Fwiw, G1 has both ConcGCThreads (for marking; 1/4th of ParallelGCThreads) and ConcRefinementThreads (for refinement; equal in count with ParallelGCThreads) which are active at the same time.
Not sure if only using ConcGCThreads (ParallelGCThreads?) is appropriate for this calculation.

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.

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?

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

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


More information about the hotspot-gc-dev mailing list