jstack, profilers and other tools

[Ron Pressler]

Hi.

Alan gave you the specifics, but I’d like to make a more general point. 

It’s important to remember that the reason to use virtual threads is to have lots of them. It is, therefore, unusual for an application that has any virtual threads to have fewer than, say, 10,000. An existing application that migrates to using virtual threads doesn’t replace its platform threads with virtual threads, but spawns a virtual thread for each of its *tasks*. As a consequence, virtual threads are very numerous and most of them are very short lived, and the simple thread dump format used by jstack will not be informative. The set of mounted virtual threads is essentially a random sample of less than 1% of threads (8-30 threads out of at least 10K), and probably not useful to understanding what the application is doing. That is why a new kind of thread dump, designed for these circumstances, is introduced.

— Ron

> On 11 Jul 2022, at 18:37, Egor Ushakov <egor.ushakov at jetbrains.com> wrote:
> 
> Hi all,
> 
> I'm trying to prepare IntelliJ for loom and have some trouble understanding how tooling should be modified:
> 1. with debugger it is more or less ok - virtual threads are separated from carrier threads, stack are separate and debugger is responsible for showing all of this.
> 2. thread dumps (jstack as an example) - no virtual threads are shown, carrier threads stacks are truncated even if they are doing some work in the mounted virtual threads. It is not clear for me how users should understand what (even mounted) virtual thread are doing. Should we always switch to the new json format? Should user decide on which format to use? Previously thread dumps way an easy way to grab "what the app is doing" at the moment. Is there a way to achieve this now? Or this way should be abandoned?
> 3. Profilers - with jfr I was not able to see any sampling data for virtual threads, where should I find it? With async-profiler (using AsyncGetCallTrace) it is still posible to see the sampling data (and merged stacks when vthread is mounted) - good. Hopefully this wont break?
> 
> Could someone please clarify this?
> 
> Thanks,
> Egor
> 
>