[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8303242: ThreadMXBean issues with virtual threads
From:       Mandy Chung <mchung () openjdk ! org>
Date:       2023-02-28 21:10:08
Message-ID: r2bT4hw4Tz4GrUCZFkwhkc-SBUK6-G5rcNrt-h-G1q4=.f6d1f0f6-a4a4-41b2-b63d-3ef958500c4b () github ! com
[Download RAW message or body]

On Mon, 27 Feb 2023 12:23:09 GMT, Alan Bateman <alanb@openjdk.org> wrote:

> This PR covers a number of issues with j.l.management.ThreadMXBean, and the \
> JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads \
> in use. 
> As background, ThreadMXBean was re-specified in Java 19 to support the monitoring \
> and management of platform threads. It does not support virtual threads as their \
> potential number, and the need to find a thread by id, does not make sense for this \
> API. At the same time, JDK 19 introduced an alternative implementation of virtual \
> threads for Zero and ports without continuations support in the VM. This \
> alternative implementation of virtual threads means a JavaThread per virtual thread \
> and so requires filtering to ensure that the API behaves as specified. For the \
> initial implementation, the filtering was done in the ThreadMXBean implementation. \
> That works for most functions but not for getThreadXXXTime(long[]) and \
> getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the \
> management code. 
> The changes in this PR move the filtering to the management functions (jmm_XXX) so \
> they only return information about platform threads. There are some minor \
> adjustments to the API docs (see linked CSR). Test coverage is expanded as we \
> didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK \
> 19. 
> Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity \
> checking that --with-jvm-variants=minimal builds as some of this code is not \
> compiled in with minimal VM builds.

The "Thread CPU time" section in the class spec of ThreadMXBean can also be \
clarified.

src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 529:

> 527:     /**
> 528:      * Tests if the Java virtual machine implementation supports CPU time
> 529:      * measurement for any platform thread.

This change can also apply in `@return` (line 538)

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 258:

> 256:             long tid = Thread.currentThread().threadId();
> 257:             long cpuTime = bean.getThreadCpuTime(tid);
> 258:             assertEquals(-1L, cpuTime);

Am I correct that `getThreadCpuTime(tid)` returns -1 for the current thread is a \
virtual thread whereas `getCurrentThreadCpuTime` throws UOE in the current \
implementation?

`getCurrentThreadCpuTime` is specified to be equivalent to calling \
`getThreadCpuTime(Thread.currentThread().threadId()`.

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

PR: https://git.openjdk.org/jdk/pull/12762


[prev in list] [next in list] [prev in thread] [next in thread]