On Fri, 24 Oct 2025 18:27:47 GMT, Jonas Norlinder <[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.
>
> 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

Reply via email to