JDK-8284296 : Thread dump issues
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: tools
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-04-04
  • Updated: 2025-05-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8302185 - jdk.trackAllThreads should be enabled by default
Relates :  
JDK-8287008 - Improve tests for thread dumps in JSON format
Relates :  
JDK-8356870 - HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates
Sub Tasks
JDK-8287080 :  
Document format of thread dump in JSON format - Closed
Description
jcmd Thread.dump_to_file requires a file to be specified. Some users may want the output generated to stdout, possible by specifying the file as "-" but it limits the output to about 16k so will appear truncated when there are huge number of threads. Should this be re-visited to default to stdout if a file is not specified? Could an OutputStream could be created that is backed by the pipe connection to the tool so that the output doesn't need to be buffered off-heap?

jcmd Thread.dump_to_file triggers the Attach Listener thread in the target VM to generate the thread dump. The Attach Listener is a daemon thread so does not prevent the VM from exiting. Should this command prevent the VM from exiting? The issue dates back to JDK 6 but may not have been noticed because other Java commands executed by the Attach Listener are short lived.
Comments
I've updated the issue description to reduce it down to remaining work in this area. As regards the comments from 2023 about lock information in this thread dump: JDK-8356870 proposes to bring this from the loom repo to main-line. As regards the thread dump including all threads, including unmounted virtual threads started directly with the Thread API, this was done via the changes for JEP 444 that made virtual threads a permanent API in JDK 21. As regards streaming to the output to the jcmd tool. This can be looked at once JDK-8336723 has infrastructure in place. See also JDK-8319055 for jcmd commands implemented in the VM.
24-05-2025
There is ongoing work in this area to APIs for navigating the tree of thread groupings, with access to locks held and waiters, to allow deadlock detection and more. I might close this issue to avoid any confusion based on where this area was at a year ago.
09-02-2023
I agree with David H.; the lack of lock information would make troubleshooting lock-related issues a total nightmare. This is something our support engineers do on an almost daily basis and breaking it would make helping impacted users nearly impossible. We need both intrinsic monitor *and* j.u.c lock information available for all threads. I am also very concerned about the fact that we default to not tracking all virtual threads. As it stands now, any code in a user's tech stack could silently spawn a virtual thread that takes an important lock and never releases it, leaving the user with absolutely no way to identify the cause. Requiring users to reboot with a command line option and reproduce the issue would be a drastic regression in serviceability. Perhaps there could be a way to enable tracking dynamically when the first untracked virtual thread is created? If the overhead of tracking these threads is truly cost-prohibitive, then the API to spawn them should be removed before the preview ends and we are stuck with a new s.m.Unsafe.
09-02-2023
It would also be useful to enhance the dump with information about locks, as regular thread dumps do, so that e.g. #32 "" virtual java.base/jdk.internal.vm.Continuation.yield(Continuation.java:357) java.base/java.lang.VirtualThread.yieldContinuation(VirtualThread.java:403) java.base/java.lang.VirtualThread.park(VirtualThread.java:532) java.base/java.lang.System$2.parkVirtualThread(System.java:2612) java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:54) java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:219) java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:754) java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:990) java.base/java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:959) Deadlock.lockUnlock(Deadlock.java:47) Deadlock.lambda$main$6(Deadlock.java:24) would indicate which RRWL instance was being locked.
30-11-2022