RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime

Serguei Spitsyn sspitsyn at openjdk.org
Sat Oct 18 00:45:01 UTC 2025


On Fri, 17 Oct 2025 22:57:43 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Thanks for making this happen! I think it looks good from my point of view, I have just one question, is it safe to skip the check for os::is_thread_cpu_time_supported? One might ask why CPUTimeUsage does not handle that, but since these methods are also used by internal GC functionality this was intentionally omitted for performance reasons (and some GCs like G1 won't run if thread CPU time is not supported so that call is not always needed). I'm no JVMTI expert so this might be fine, like how its fine for G1 to omit calling it, but just wanted to ask.

Thank you for looking at it and comment! Yes, I was thinking about this check but have not came to any conclusion yet. Yes, I was thinking if this check would be simpler to add to the `CPUTimeUsage` and understand your point about performance reasons. From the other hand it is possible for `CPUTimeUsage::GC::total()` to just always return `-1` if `!os::is_thread_cpu_time_supported()`. While it is better to have it implemented in some common place, I'm not very religious about it and could add it to the JVMTI functions. One problem with that is consistency. There is no such check in the existing JVMTI functions like `GetThreadCpuTime()`,  `GetCurrentThreadCpuTime()`, `GetThreadCpuTimerInfo()` and `GetCurrentThreadCpuTimerInfo()`.
However, I've just added this check to the `GetTotalGCCpuTime()`. Please, let me know your opinion.

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

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


More information about the serviceability-dev mailing list