<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 23/10/2024 12:15, Nathan Reynolds wrote:<br>
<blockquote type="cite" cite="mid:CALMUwcoyhTXU=0L8DD3XMCq9Xp5uk03kdbArjp_jYvjB_V5Nug@mail.gmail.com">
<div dir="ltr">
<div>How do I list all the virtual threads in a JVM? <code>ThreadMXBean.dumpAllThreads()</code>,
<code>ThreadMXBean.getAllThreadIds()</code>, <code>ThreadGroup.enumerate()</code>,
and <code>Thread.getAllStackTraces()</code> do not return
virtual threads. See my question at <a class="gmail-x_moz-txt-link-freetext moz-txt-link-freetext" id="gmail-LPlnk648813" rel="noopener noreferrer" target="_blank" href="https://stackoverflow.com/questions/79110874/list-the-virtual-threads-in-java" moz-do-not-send="true">https://stackoverflow.com/questions/79110874/list-the-virtual-threads-in-java</a>.</div>
<div><br>
</div>
<div>I can see how these APIs would not scale for virtual
threads. What are the thoughts for an API to list all the
virtual threads? For an in-process API, would an API that
returns Stream<Thread> scale? I am not sure how an
MXBean API can stream Threads to make it scale.<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Right, the cited APIs were all re-specified in JDK 19 to only
enumerate platform threads. This extends to JVMTI APIs and the
debugger wire protocol too. None of these APIs scale, e.g.
ThreadMXBean requires a mapping of thread identifier to Thread for
local use, getting a snapshot of all virtual Thread objects in the
heap would require a stop-the-world and/or walking the heap.<br>
<br>
There are lots of ideas for expanding the serviceability APIs in
this area. Some of these will require significant changes to the
debugger protocol and agent. In the mean-time, the only
serviceability that include all threads are the heap dump and the
thread dump taken with jcmd Thread.dump_to_file.<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
</body>
</html>