jstack, profilers and other tools

[Egor Ushakov]

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.

As for jfr - I was able to view the samples from virtual threads, for 
some reason jmc 8.2 does not show them, but they are in the snapshot.

Egor

On 11.07.2022 20:25, Alan Bateman wrote:
> On 11/07/2022 18:37, Egor Ushakov 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?
>
> The stack trace of the carrier and the virtual thread are 
> intentionally separate. So if a virtual thread throws an exception 
> then you won't see the carrier stack traces. It's the same thing with 
> thread dumps: the stack trace of a carrier thread won't show the stack 
> frames of a mounted virtual thread, and vice-versa. There is more on 
> this in the JEP.
>
> The HotSpot thread dump (jcmd Thread.print, jstack) only shows 
> platform threads (the threads that the VM knows about). The new thread 
> dump (with the HotSpotDiagnisticMXBean API or jcmd 
> Thread.dump_to_file) will print both platform and virtual threads. The 
> plain text and JSON formats can be used to get a view of what the 
> application is doing. The JSON format is intended to be parsed of course.
>
>> 3. Profilers - with jfr I was not able to see any sampling data for 
>> virtual threads, where should I find it? 
>
> I'm not aware of any issues. I checked with Markus Grönlund (works on 
> JFR) and he's not aware of any issues either. What tool are you are 
> using to look at the recording? Do you see the virtual threads when 
> you use `jfr print --events JDK.ExecutionSample <recording>`?
>
> -Alan