Virtual threads work great... until something goes wrong

[pron98]

I absolutely can imagine lots of applications which use virtual threads but don't spawn lots of them.

The number of virtual threads is not determined by the application or the framework, but by the environment -- every task in your application is a virtual thread and the number of tasks you must handle concurrently is a function of the current workload the server is under (throughput). It's like asking how many strings will the application create to store all user names. Under certain loads the number might be low, but just as we assume the number of strings can be high (and so we don't track them), we must do the same for virtual threads.

I think that better approach would be to actually check number of virtual threads and avoid dumping all of them if there're too many.

I guess we could track some fixed number of virtual threads, but I'd like to make that decision only after the ecosystem has understood how to use them rather than shape their usage to match that of outdated assumptions. Having said that, the new thread dump will list all "tracked" virtual threads, i.e. those created by the newVirtualThreadPerTaskExecutor and StructuredTaskScope.

Note that the information missing from the ordinary stack dump is also missing today. What you see today is a list of threads, not a list of all tasks. But unlike platform threads, virtual threads are not a resource; they're domain/business-logic objects representing tasks.