Monitoring virtual threads via thread dumps

[Stig Rohde Døssing]

Thank you both. This makes sense. We'll look into JFR for
monitoring/profiling. It's good to hear the new thread dumps will be
expanded.

Den ons. 29. mar. 2023 kl. 14.49 skrev Ron Pressler <ron.pressler at oracle.com
>:

>
>
> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230330/5581e708/attachment.htm>