On Mon, 4 Aug 2025 19:53:24 GMT, Jonas Norlinder <d...@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
