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

[Man Cao]

On Tue, 26 Aug 2025 10:04:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>>  - accumlate concurrent_gc_impact_time
>>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>>  - cleanup after merge
>>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>>  - Merge branch 'NormalizeTiming' into ConcCPUImpact
>>  - Thomas suggestion
>>  - Thomas Review
>>  - reorder
>>  - concurrent gc impact
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/999761d0...c65429ad
>
> src/hotspot/share/gc/g1/g1Analytics.cpp line 167:
> 
>> 165:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
>> 166:   uint num_cpus = (uint)os::active_processor_count();
>> 167:   double concurrent_gc_impact_time = _concurrent_gc_cpu_time_ms / num_cpus;
> 
> I'd expect to see `ConcGCThreads` somewhere in the formula, but maybe this is enough.

Now I think the number of active GC threads could be irrelevant for converting CPU time to mutator wall-clock time.
The idea is more like "what if the CPU used by concurrent GC is used by mutator threads instead". Then the number of active mutator threads is a more appropriate divisor.

Anyway, we still have the under-estimation problem, because applications typically do not use up all active processors. It is impractical to fully solve this problem. The current approach and acknowledging the under-estimation looks good.

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

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