Hi all, maybe this channel is better, could anyone answer please
-------- Forwarded Message --------
Subject: Fwd: Add a jcmd diagnostic command to provide a full combined
dump of all platform and virtual threads ([Thread.print] +
[Thread.dump_to_file -format=json]).
Date: Wed, 17 Jun 2026 15:18:53 +0200
From: Maria Sokolova <[email protected]>
To: Egor Ushakov <[email protected]>
---------- Forwarded message ---------
From: *Maria Sokolova* <[email protected]>
Date: Tue, Jun 16, 2026 at 5:33 PM
Subject: Add a jcmd diagnostic command to provide a full combined dump
of all platform and virtual threads ([Thread.print] +
[Thread.dump_to_file -format=json]).
To: <[email protected]>
Hi folks,
I wonder if there is, or could be, a supported way to obtain a single
point-in-time thread dump that combines the information currently
available from two different diagnostic commands:
* /jcmd <pid> Thread.print/ — full platform-thread dump, including
monitors, object/heap addresses, native thread info, etc.
* /jcmd <pid> Thread.dump_to_file -format=json/ — dump of virtual
threads, including mounted and unmounted virtual threads and their
thread-container structure.
These commands work quite differently: /Thread.print/ runs as a VM
operation at a safepoint, while /Thread.dump_to_file/ is designed to
avoid pausing the application and is implemented via
/jdk.internal.vm.ThreadDumper/ and sequential collection of
/ThreadSnapshots/ .
And there is no way to compose these public commands to get the combined
"atomic" snapshot.
Would OpenJDK consider supporting such a combined dump, for example as a
new option for /jcmd/ that captures, *at one safepoint*, both the
complete platform thread information and virtual thread information,
including mounted/unmounted virtual thread stacks and ideally the
thread-container hierarchy?
We also considered implementing this with a native JVMTI agent, which
would: suspend all platform and virtual threads, collect thread data
through JVMTI, then resume.
However, this has some limitations:
* there is no JVMTI API to get all currently live virtual threads
unless the agent is loaded from startup and tracks
/VirtualThreadStart/ / /VirtualThreadEnd /events
* and there is no API to retrieve the virtual-thread container hierarchy
Overall, such a combined snapshot would be very useful for diagnostics,
even if it is potentially expensive for applications with very large
numbers of virtual threads.
