jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time

[Jonas Norlinder]

On Sat, 27 Sep 2025 14:13:48 GMT, Alan Bateman <alanb 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.
>
> This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this.

Thanks @AlanBateman. I did first consider `GarbageCollectorMXBean` but given that this interface only exposes a sub-component of the GC at a time it might not fit in well with a systemic method that samples the total GC CPU time.

To clarify what I mean with "exposing a sub-component at a time"; consider the following

List<GarbageCollectorMXBean> list = java.lang.management.ManagementFactory.getGarbageCollectorMXBeans();
for (GarbageCollectorMXBean gcMXBean : list) {
     System.out.println(gcMXBean.getName());
}

Its output will be

$ java -XX:+UseSerialGC Main.java
Copy
MarkSweepCompact

$ java -XX:+UseParallelGC Main.java
PS MarkSweep
PS Scavenge

 java -XX:+UseG1GC Main.java
G1 Young Generation
G1 Concurrent GC
G1 Old Generation

$ java -XX:+UseZGC Main.java
ZGC Minor Cycles
ZGC Minor Pauses
ZGC Major Cycles
ZGC Major Pauses


So no `GarbageCollectorMXBean` for any collector would map nicely to a systemic method like `getGcCpuTime()`. I could be wrong but I don't think there will be many use cases where a user wants/needs to know CPU time per each GC component nor does we currently support such granularity. If we look at the API for `MemoryMXBean` (https://docs.oracle.com/en/java/javase/25/docs/api/java.management/java/lang/management/MemoryMXBean.html) we can se that it do already include a couple of methods to query a "systemic property":

* `getHeapMemoryUsage()`
* `getNonHeapMemoryUsage()`

Additionally it includes a method to request a GC, which made me think that this could be a good fit for this method. That being said if my above observations are incorrect or there is a more appropriate place to put this method I'm happy to update the PR.

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

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