RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime [v3]
Alan Bateman
alanb at openjdk.org
Sun Oct 19 10:25:01 UTC 2025
On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>>
>> Introduce:
>> - new capability: `can_get_gc_cpu_time`
>> - new JVMTI functions:
>> - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>> - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>>
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>>
>> Testing:
>> - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> fix a typo in GetGCCpuTimerInfo: long => jlong
> There is also interest to get the same performance data from JVMTI.
Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).
As a general point, the JVMTI spec doesn't have much support for monitoring GC. It has GC start/end events that date from the original spec when collectors were all STW and it hasn't evolved since to model more modern collectors.
I'm sure CPU time spend on GC is important to many profilers but I'm also wondering if JVMTI is the right API for modern profilers to be using. JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.
(n passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419554152
More information about the serviceability-dev
mailing list