jstack, profilers and other tools

[Alan Bateman]

On 11/07/2022 19:59, Egor Ushakov wrote:
> Thanks Alan!
>
> I've read jep and the user approach to virtual threads is still 
> unclear to me:
> on the one hand for writing the code they are made to look and feel 
> like "regular" threads, but the approach for tooling seems to be very 
> different
> - virtual threads are separated almost everywhere and seems to require 
> very different observability techniques.
> I'm fine with supporting all kinds of approaches, just want to make 
> sure that it will be clear for users how to approach this.
> For me it is not yet clear.

The threads are distinct and the mental model should be that they have 
separate stack traces. It would be misleading for APIs or Java tooling 
to show carrier frames in the virtual thread stack. There will be native 
tools, esp. those that attach via /proc, that don't know about virtual 
threads and there isn't much we can do about that.

I think part of your mail is asking why the HotSpot thread dump 
(triggered by ctrl-\, jcmd Thread.print or the older jstack tool) 
doesn't include virtual threads. Virtual threads are just objects in the 
heap and we decided early on that changing this to walk the heap and 
print tens of thousands of threads would be not be helpful. It has been 
modified in a small way to identify the threads that are used as 
carriers but that's about it. The new thread dump that is added includes 
both platform and virtual threads and is intended to be parsed. Many 
virtual threads are likely to have the same stack trace and so lends 
itself to deduplication for example.  In conjunction with JEP 428, 
tooling will be able to observe the task hierarchy.

Thanks for confirming that the sampling with JFR is working for virtual 
threads. Hopefully JMC will be updated in time to support virtual threads.

-Alan