RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]

[Kevin Walls]

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Questions that this change brings up to me:

Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area?
If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

How do we make it easy for somebody to add useful features in the right place...

Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.

The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

The originally proposed JavaDoc had some HotSpot-specific terms in it, which maybe did not fit.  But they could still be valid if rephrased as a note of examples of the kinds of things that an implementation may need to do.

I'm wondering if the com.sun.management... interfaces made sense as a way to add features outside of an original JSR spec.  Maybe that was their intent.  But are we still in that world, do we still need to do that?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3386013198