On Sat, 27 Sep 2025 14:13:48 GMT, Alan Bateman <[email protected]> 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
