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

Alan Bateman alanb at openjdk.org
Sun Oct 26 14:20:09 UTC 2025


On Fri, 24 Oct 2025 18:27:47 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:
> 
>   Review fixes

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 300:

> 298:      * nanoseconds, or {@code -1}.
> 299:      *
> 300:      * @since 26

The latest API docs is good, thanks for accepting all the comments/suggestions to get this right.

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 305:

> 303:     default public long getTotalGcCpuTime() {
> 304:         return -1;
> 305:     };

No need for the semicolon after the closing brace. No need for `public` modifier either but okay to leave it as event the abstract methods in this interface have it, even if not explicitly needed as they are public anyway.

test/jdk/java/lang/management/MemoryMXBean/GetTotalGcCpuTime.java line 44:

> 42: import java.lang.management.ThreadMXBean;
> 43: 
> 44: public class GetTotalGcCpuTime {

This test will need re-work.

What is the reason for launching a sub-process? The child process starts 4 * ncores threads, the main thread in the child process then exits with status 0. It would be a lot simpler to have a single VM and verify that the GC time increases monotonically when there are busy mutators and/or explicit GC.

The API is designed to work in conjunction with OperatingSystemMXBean.getProcessCpuTime so you can test them together to ensure that GC cpu time is <= process cpu time.

The test can implement MemoryPoolMXBean, just the abstract methods, so you can test the default method.

Look at other tests to see how `@requires` is used in test selection, e.g. tests that uses -XX:+UseZGC will have `@requires vm.gc.Z` in the test description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463840541
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463839299
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463846623


More information about the serviceability-dev mailing list