Monitoring virtual threads via thread dumps

[Ron Pressler]

> On 28 Mar 2023, at 21:31, Stig Rohde Døssing <stigdoessing at gmail.com> wrote:
> 
> My first few questions relate to the ability to tell what carrier threads are spending their time on, based on thread dumps.
> 
> 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? 

The “carrier” and the virtual thread are two separate threads. When the virtual thread is mounted, the carrier is blocked — that *is* what it’s spending its time on: waiting for a virtual thread. It’s not running anything (although the OS thread that the carrier and the virtual thread share is running something).

Concatenating the virtual thread’s stack to the carrier’s stack in the old platform-thread-only thread dump will present a very incorrect picture of how the program is spending its time. For example, a Thread.sleep(100) will take 100ms overall and consume ~0ms of CPU time regardless of whether it’s run on a platform thread or a virtual thread. However, that kind of concatenated thread dump will tell two very different stories in these two situations, even though the application behaves the same: the Thread.sleep frame will occupy a stack trace for 100ms if that trace happens to belongs to a platform thread, and ~0ms if it happens to belong to a virtual thread. I.e. the profile you’ll get would be wrong.

The mechanism by which you get a profile of what the application spends time on and how is JFR, and the new extended thread dump is useful for troubleshooting. As Alan pointed out, we’re working on expanding the information in the new thread dump.

— Ron