On Thu, 30 May 2024 16:39:03 GMT, Alan Bateman <al...@openjdk.org> wrote:

>> Print the stack traces of mounted virtual threads when calling `jcmd <pid> 
>> Thread.print`.
>
> Thanks for take this one. Here's the result with the changes in 1a75277e.
> 
> "ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31 cpu=46574.42ms 
> elapsed=47.15s tid=0x00007f81670d1a00  [0x000070000e9a4000]
>    Carrying virtual thread #24
>       at jdk.internal.vm.Continuation.run(java.base/Continuation.java:262)
>       at 
> java.lang.VirtualThread.runContinuation(java.base/VirtualThread.java:283)
>       at 
> java.lang.VirtualThread$$Lambda/0x00000001220b2868.run(java.base/Unknown 
> Source)
>       at 
> java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1726)
>       at 
> java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1717)
>       at 
> java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base/ForkJoinTask.java:1641)
>       at 
> java.util.concurrent.ForkJoinTask.doExec(java.base/ForkJoinTask.java:507)
>       at 
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base/ForkJoinPool.java:1455)
>       at 
> java.util.concurrent.ForkJoinPool.runWorker(java.base/ForkJoinPool.java:2031)
>       at 
> java.util.concurrent.ForkJoinWorkerThread.run(java.base/ForkJoinWorkerThread.java:189)
>    Carrying virtual thread #24
>       at Main.lambda$main$0(Main.java:7)
>       at java.lang.VirtualThread.run(java.base/VirtualThread.java:381)
> 
> 
> Note that the line "Carrying virtual thread  #24" is printed twice. Also it's 
> not immediately clear that there are two stack traces. 
> 
> You'll likely get different opinions on how mounted virtual threads should be 
> presented.  A few things to try
> - indent the stack trace of the mounted virtual thread
> - list the mounted virtual threads at the end

Thanks for your comments @AlanBateman and @dholmes-ora ! 

- The format proposed by @dholmes-ora definitely makes sense and I'll of course 
drop the duplicated "Carrying" statement.

- Regarding using `JavaThread::print_vthread_stack_on`, I agree that it'd be 
good to use it instead of creating a new way of printing stack traces. However 
`print_vthread_stack_on` does not have the `const` modifier so it cannot be 
called directly from `Thread.print_on`. Making `print_vthread_stack_on` more 
strict, seems to be fairly complicated and I don't know if I'd be OK with 
relaxing the `const` constraint in `Thread.print_on` for the purpose of reusing 
`print_vthread_stack_on`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2141946811

Reply via email to