Monitoring virtual threads via thread dumps

[Alan Bateman]

On 28/03/2023 21:31, Stig Rohde Døssing wrote:
> :
>
> For the profiling use case we have, we basically would like to see a 
> snapshot of what code the application is executing at a given moment. 
> Thread dumps for carrier threads don't include the stack of the 
> virtual thread being executed. Would it be possible to include these 
> stacks, or is there a reason it is preferable not to list them?

There are separate threads with their own stack traces. Having the 
carrier frames show up in the the stack trace of a mounted virtual 
thread can also be confusing. It's a topic that probably needs more 
feedback on what is useful. For now, the -XX:+ShowCarrierFrames option 
can be use to see the frames.

>
> :
>
> Unrelated to the question of using dumps for profiling, I noticed that 
> when using the HotSpotDiagnosticMXBean to dump threads, virtual 
> threads created directly via Thread.ofVirtual are not listed, you have 
> to use Executors.newVirtualThreadPerTaskExecutor. Should this be 
> called out more strongly in the documentation? I don't see this 
> mentioned outside the JEP, and it caught me by surprise, which isn't 
> ideal since I probably wouldn't have thought to check this kind of 
> thing in a real application, and it would make debugging such an 
> application harder.
This is also a topic that needs feedback. Threads that are in some 
"grouping", a thread-per-task-executor, or StructuredTaskScope, will be 
shown in the thread dump in that grouping. Threads created directly with 
the Thread API aren't in any grouping. For now, running with 
-Djdk.trackAllThreads=true will ensure that all threads in the root 
grouping do show up in the thread dump. As I say, this is an area that 
needs more feedback.

-Alan