On Mon, 27 Feb 2023 12:23:09 GMT, Alan Bateman <al...@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
