JDK-8302185 : jdk.trackAllThreads should be enabled by default
  • Type: Enhancement
  • Component: core-svc
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2023-02-10
  • Updated: 2024-07-09
  • Resolved: 2023-06-05
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.
JDK 21
21Resolved
Related Reports
Duplicate :  
JDK-8309406 - Change jdk.trackAllThreads to default to true
Relates :  
JDK-8284296 - Thread dump issues
Relates :  
JDK-8302184 - full lock information for virtual threads in thread dumps
Relates :  
JDK-8336061 - Virtual threads cannot be GC'ed before they terminate
Relates :  
JDK-8309406 - Change jdk.trackAllThreads to default to true
Description
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.)
Comments
A duplicate of JDK-8309406
05-06-2023
Changed our minds on this.
05-06-2023
Will reconsider at a later date.
13-04-2023
It's not just the memory impact. It's also startup impact, plus, it's a valid use case to write a virtual thread that never terminates but is collected when it can no longer do any work (e.g. it processes a potentially infinite stream). A "tracked" thread cannot be collected until it terminates.
14-02-2023
In the meantime, I did some exploring / testing to fill in some of the details on the memory impact of enabling trackAllTreads. Looking at the source, it appears each thread started with the “non-recommended” Thread API will instantiate one additional ConcurrentHashMap$Node, which on the current 20 EA builds weighs in at 32-bytes per instance (compressed oops enabled). So we would expect approximately 32 MB per million threads of additional heap overhead. Testing is in line with what we expect: === Thread API === no tracking: used 856188K used 854979K used 854521K tracking: used 895095K used 898784K used 896399K === Executor API === no tracking: used 975480K used 974050K used 972577K tracking: used 973389K used 971750K used 973279K Each test was run 3 times. (The above results show something closer to 40~45 MB larger live set size. I assume some sort of alignment / fragmentation or other similar overhead can account for the small discrepancy.) In all cases the total live-set size was of dominated by the much larger instances like ScheduledThreadPoolExecutor$ScheduledFutureTask (retaining almost 400 bytes per thread). My test case intentionally used very small stacks to minimize the impact of StackChunk:s on the overall live-set size. Any non-trivial application would consume significantly more per thread to copy the longer stack to the heap. conclusions: - trackAllThreads has no impact on usage of the recommended executor(service)-based APIs - trackAllThreads appears to have a worst-case overhead of around a 5% increase in the per thread heap consumption
14-02-2023
First, virtual threads created via the recommended mechanisms -- Executors.newVirtualThreadPerTaskExecutor or StructuredTaskScope -- show up in the thread dump. It's important to understand that virtual threads play a very different role from platform threads. They are not managed resources but business tasks, and a far smaller portion of tasks was observable in thread dumps than what is observable now thanks to virtual threads. The new thread dump increases the information made available for observation and the number of observable tasks dramatically. However, increasing the portion of observable tasks all the way to 100% by making all virtual threads always observable by default may have a significant impact on the weight of the construct, so we will not do so now. We may revisit this decision in a few years.
10-02-2023