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.
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. Íñigo On Wed, Jun 5, 2024 at 6:52 AM Alan Bateman <alan.bate...@oracle.com> wrote: > On 04/06/2024 21:52, Iñigo Mediavilla wrote: > > Hello, > > > > While there's ongoing work on: > > > > https://github.com/openjdk/jdk/pull/19482 > > > > to add the stack trace of mounted virtual threads to the `jcmd <pid> > > Thread.print` command, I'm starting to think about how I could do to > > print the stack trace for virtual threads from `jstack` but I'm not > > sure about what would be the best approach, so I'd be happy to get > > people's thoughts on the topic. > > JDK-8330846 is about showing the stack traces of mounted virtual > threads, I don't think pull/19482 should be expanded to do anything > else. For the PR then I think you are just waiting for Thomas Stuefe's > change with support for automatic indentation and of course converging > on some details of the output. > > If you are asking if it should include the stack traces of unmounted > virtual threads then we decided some time ago to not do that. The > Thread.print commands runs as a VM operation so the at a safepoint. > Adding more work to that, to walk the heap to find virtual thread > objects, would just increase the STW time. The other issue is that the > output (text format) doesn't scale to hundreds of thousands of threads. > You might ask about de-duplication but that is just adding more overhead > to the thread dump and may be better left to tools that process the > thread dump. These are issues/reasons for Thread.dump_to_file. It uses > the tree of thread groupings to find all threads. > > -Alan >
