To support a number of different troubleshooting scenarios, we need a simple way to dump *all* threads, not just a subset of threads. Limiting thread dumps to only threads started with a particular API or currently blocking on I/O is not sufficient. For example, thread dumps are the most reliable and heavily used way to troubleshoot deadlocks and other lock-related issues. Any issue where a "thread dump" (Thread.dump_to_file) does not include all of the threads directly involved in the issue would be profoundly more difficult to investigate.
This functionality needs to be enabled right OOTB as most users expect to be able to troubleshoot issues the first time they happen. Expecting users to add a command line option (assuming they can even find it) and then wait for the issue to reproduce is not reasonable.
(Note that the usefulness of thread dump described above is closely tied to JDK-8302184. The above description assumes JDK-8302184 will be resolved.)
This functionality needs to be enabled right OOTB as most users expect to be able to troubleshoot issues the first time they happen. Expecting users to add a command line option (assuming they can even find it) and then wait for the issue to reproduce is not reasonable.
(Note that the usefulness of thread dump described above is closely tied to JDK-8302184. The above description assumes JDK-8302184 will be resolved.)
- duplicates
-
JDK-8309406 Change jdk.trackAllThreads to default to true
- Resolved
- relates to
-
JDK-8284296 Thread dump issues
- Open
-
JDK-8309406 Change jdk.trackAllThreads to default to true
- Resolved
-
JDK-8336061 Virtual threads cannot be GC'ed before they terminate
- Closed
-
JDK-8302184 full lock information for virtual threads in thread dumps
- Open