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