RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime [v3]

[David Holmes]

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

I have a few issues with the spec and implementation, but they are easily addressed.

I'm not sure this functionality is really JVMTI worthy but if Jonas thinks this is useful for GC profiling then I will take hs word for it.

src/hotspot/share/prims/jvmti.xml line 11288:

> 11286:             On return, points to the time in nanoseconds.
> 11287:             This is an unsigned value.  If tested or printed as a jlong (signed value)
> 11288:             it may appear to be a negative number.

This seems to contradict the description that it could be relative to a value in the future and hence negative - thus it can't be "unsigned". But then I don't see how it can be as described - for this timer to be useful it must be tracking nanoseconds of CPU time consumed by GC since CPU time tracking commenced, sometime after VM startup. This has to be similar to how thread CPU time is defined.

src/hotspot/share/prims/jvmtiEnv.cpp line 3802:

> 3800:   {
> 3801:     MutexLocker hl(Heap_lock);
> 3802:     if (!os::is_thread_cpu_time_supported() ||

If it isn't supported then you can't have the capability and so won't reach here.

src/hotspot/share/prims/jvmtiEnv.cpp line 3804:

> 3802:     if (!os::is_thread_cpu_time_supported() ||
> 3803:         Universe::heap()->is_shutting_down()) {
> 3804:       *nanos_ptr = -1;

This seems wrong to me and violates the timer-info spec of this timer not jumping backwards. I think you have to cache the last returned value for this function and if you cannot calculate an updated value because of VM shutdown, then that previous value should be returned.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27879#pullrequestreview-3354987972
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443784044
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443799741
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443800932