8330846: (jstack) Add stacks of mounted virtual threads

Robert Engels robaho at icloud.com
Tue Jun 4 21:16:41 UTC 2024


I looked through this, and I don’t think the there is anything needed other than this PR. Eventually jstack creates a VM_PrintThreads command which calls the threads.cpp code.

> On Jun 4, 2024, at 3:52 PM, Iñigo Mediavilla <imediava at gmail.com> wrote:
> 
> Hello,
> 
> While there's ongoing work on:
> 
> https://github.com/openjdk/jdk/pull/19482 <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.
> 
> Based on what I've seen `jstack` seems to fetch a ThreadList of JavaThreads and then relies on a bunch of Java code that uses attribute offsets to get the values of certain attributes of the JavaThread in the VM. With those attributes the java code can obtain the data that it requires about the threads, their monitors and also to get the latest frame in the stack to be able to iterate the stack. If I were to follow the same principle, I'd have to replicate the code that was added to the VM to read the stack chunks of virtual threads in Java, knowing that it looks like that the JVM code had to be written for multiple CPU architectures, I'm a bit concern about how complex following that approach would be.
> 
> I considered following the approach used by `ThreadDumper.java`, that relies on `ThreadContainers` to get the virtual threads and then iterates over `Thread.getStackTrace` for the virtual thread. But I don't think that would work because I don't think the `ThreadContainers` can be accessed from `Jstack`.
> 
> So I'm basically a bit blocked, and I think that I'd need some help from people that have followed loom more closely and have a clearer view of things and can probably provide me with hints on how to approach the problem differently.
> 
> Thanks in advance for your help.
> 
> Best
> 
> Íñigo Mediavilla Saiz
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240604/bae3afa9/attachment.htm>


More information about the loom-dev mailing list