<div dir="ltr"><div>Thanks, Alan. Sorry, I wasn't clear in my message. I wasn't thinking about including unmounted threads in the output of `Thread.print`, I agree with you that besides the formatting things that still need to be fixed there's no need to add more changes to the `Thread.print` command in the context of 8330846.<br><br>My doubts were related to the fact that 8330846 also refers to including the stack of mounted threads in the output of `jstack` and I'm not sure about what's the best way to implement that. In my previous message, I explained some approaches that I looked into to have mounted virtual threads in `jstack` but I'm not sure about them.<br><br></div>Íñigo<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 5, 2024 at 6:52 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/06/2024 21:52, Iñigo Mediavilla wrote:<br>
> Hello,<br>
><br>
> While there's ongoing work on:<br>
><br>
> <a href="https://github.com/openjdk/jdk/pull/19482" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/19482</a><br>
><br>
> to add the stack trace of mounted virtual threads to the `jcmd <pid> <br>
> Thread.print` command, I'm starting to think about how I could do to <br>
> print the stack trace for virtual threads from `jstack` but I'm not <br>
> sure about what would be the best approach, so I'd be happy to get <br>
> people's thoughts on the topic.<br>
<br>
JDK-8330846 is about showing the stack traces of mounted virtual <br>
threads, I don't think pull/19482 should be expanded to do anything <br>
else. For the PR then I think you are just waiting for Thomas Stuefe's <br>
change with support for automatic indentation and of course converging <br>
on some details of the output.<br>
<br>
If you are asking if it should include the stack traces of unmounted <br>
virtual threads then we decided some time ago to not do that. The <br>
Thread.print commands runs as a VM operation so the at a safepoint. <br>
Adding more work to that, to walk the heap to find virtual thread <br>
objects, would just increase the STW time. The other issue is that the <br>
output (text format) doesn't scale to hundreds of thousands of threads. <br>
You might ask about de-duplication but that is just adding more overhead <br>
to the thread dump and may be better left to tools that process the <br>
thread dump. These are issues/reasons for Thread.dump_to_file. It uses <br>
the tree of thread groupings to find all threads.<br>
<br>
-Alan<br>
</blockquote></div>