8368527: JMX: Add an MXBeans method to query GC CPU time

[JonasNorlinder]

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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Change requires CSR request JDK-8368529 to be approved
• Commit message must refer to an issue

Issues

• JDK-8368527: JMX: Add an MXBeans method to query GC CPU time (Enhancement - P4)
• JDK-8368529: JMX: Add an MXBeans method to query GC CPU time (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537
$ git checkout pull/27537

Update a local copy of the PR:
$ git checkout pull/27537
$ git pull https://git.openjdk.org/jdk.git pull/27537/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27537

View PR using the GUI difftool:
$ git pr show -t 27537

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27537.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back JonasNorlinder! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@JonasNorlinder The following labels will be automatically applied to this pull request:

• core-libs
• hotspot-runtime
• jmx
• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[JonasNorlinder]

/label add hotspot-gc

[openjdk]

@JonasNorlinder
The hotspot-gc label was successfully added.

[AlanBateman]

/label remove core-libs

[openjdk]

@AlanBateman
The core-libs label was successfully removed.

[AlanBateman]

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.

[JonasNorlinder]

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.

[mlbridge]

Webrevs

• 00: Full (ae29e031)

[dholmes-ora]

I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request

[kevinjwalls]

It looks a bit odd to me to change the existing define of UPTIME here.
OK it is not a public interface used between different versions, and people should not be mixing up jmm.h and management implementations... But usually we would just add the new definition? (items below are not strictly grouped by name) Maybe this is just a nit, and only makes cross-version comparisons easier.

Looks good overall.