JDK-8364638 : Refactor and make accumulated GC CPU time code generic
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-08-04
  • Updated: 2025-09-03
  • Resolved: 2025-08-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 b13Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
With JDK-8359110 a framework to measure GC CPU time was introduced. 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 the newly added code can be refactored into something more generic.
Comments
Changeset: fb651fd6 Branch: master Author: Jonas Norlinder <jonas.norlinder@oracle.com> Committer: Albert Mingkun Yang <ayang@openjdk.org> Date: 2025-08-21 14:05:36 +0000 URL: https://git.openjdk.org/jdk/commit/fb651fd6d246e69b42363e050eb8d96afb633eed
21-08-2025

[~dcubed] Thank you for the PING! I agree it can be interesting to support in JVMTI. I'm curious what kind of function should we consider to add. Would something like below work? : GetGCThreadsCpuTime(jvmtiEnv* env, jlong* nanos_ptr); GetVMThreadCpuTime(jvmtiEnv* env, jlong* nanos_ptr); Also, I'm not sure if we want the CpuTimerInfo functions as well: GetGCThreadsCpuTimerInfo(), GetVMThreadCpuTimerInfo()
13-08-2025

Ping [~sspitsyn] - sounds interesting from a JVM/TI POV...
04-08-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26621 Date: 2025-08-04 13:59:43 +0000
04-08-2025