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

Serguei Spitsyn sspitsyn at openjdk.org
Mon Oct 20 19:04:04 UTC 2025


On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> 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).

Alan, thank you for looking at this, the comments and good questions. I agree, we need to look at some level of completeness here. It includes the process CPU time and potentially more functionality to support modern GC's (I hope to get more insight from the GC team here). One question I've got is about all these timers and a possibility to reuse some of them. Is it right to have new timer for each CPU metric? We need some kind of overall design for all this. As I've posted earlier in reply to David for this enhancement, I rely on Jonas's justification which is in the enhancement description.

> 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.

Yes, support for modern collectors is on the table for some time.  Now seems to be a good time to make some steps in this direction.

> 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.

I hope, Jonas has answered this.

> (in passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)

Yes, it seems this function is a little bit out of this section scope. But I do not see a better section for this, and it does not deserve its own section yet. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423360087


More information about the serviceability-dev mailing list