RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v3]
Daniel D. Daugherty
dcubed at openjdk.org
Mon Aug 4 23:31:09 UTC 2025
On Mon, 4 Aug 2025 19:53:24 GMT, Jonas Norlinder <duke at openjdk.org> wrote:
>> Hi all,
>>
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>>
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>>
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>>
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>>
>> CPUTimeUsage::Runtime::vm_thread()
>>
>>
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>>
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>>
>>
>> [12.517s][info][cpu] === CPU time Statistics =============================================================
>> [12.517s][info][cpu] CPUs
>> [12.517s][info][cpu] s % utilized
>> [12.517s][info][cpu] Process
>> [12.517s][info][cpu] Total 175.7628 100.00 14.0
>> [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6
>> [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8
>> [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6
>> [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1
>> [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0
>> [12.518s][info][cpu] =====================================================================================
>>
>>
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>
> Prefer returning 0 over +/-inf,nan
Seems like JVM/TI folks will be interested also.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3152782164
More information about the hotspot-dev
mailing list