On Sat, 27 Sep 2025 11:18:58 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.

Thanks, it’s a useful function. (I would not have expected it in the memory 
bean but in the go bean, but I guess both is fine.) Some more comments inline

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

> 271:      * Returns the CPU time used by all garbage collection threads.
> 272:      *
> 273:      * <p> This include time since genesis, so the value can be

The “so the” is not too obvious to me. Maybe simplify it a bit “This includes 
time since genesis and counts activities even before the first collection 
cycle.”?

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

> 277:      * deduplication thread (if enabled). This method returns
> 278:      * {@code -1} if the platform does not support this operation
> 279:      * or if called during shutdown.

Can we explicitly state here that this is concurrent time as well as worker 
time spent during pauses but not accumulated pause times?

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

> 280:      *
> 281:      * @return the total CPU time for all garbage collection
> 282:      * threads in nanoseconds.

Not sure did I miss the discussion, other methods like 
getTotalCompilationTime() return millis, is it ok or required to use new units 
here?

test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73:

> 71:                 while (true) {
> 72:                     long gcCpuTimeFromThread = 
> mxMemoryBean.getGcCpuTime();
> 73:                     if (gcCpuTimeFromThread < -1) {

None of the tests actually test if it is ever != -1 or if it is monotonically 
increasing or under which conditions (go? Platform? Build flags?) it is 
unsupported?

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

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3282521865
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389806062
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389808338
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389815933
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389822026

Reply via email to