Deadlocks in virtual threads - was RFR: 8285196: Deadlock reporting prints carrier thread when virtual thread is in deadlock cycle

Alan Bateman Alan.Bateman at oracle.com
Mon Jun 20 18:20:10 UTC 2022


On 20/06/2022 18:33, Dr Heinz M. Kabutz wrote:
> :
>
> Thanks for your quick reply Alan - that's what I suspected.

The JMX section in JEP 425 provides a summary but doesn't go into the 
rational.


>
> I guess the clue will be carrier threads stuck trying to run 
> continuations, with the cpu time not increasing over time?
>
>
> "ForkJoinPool-1-worker-1" #31 [25347] daemon prio=5 os_prio=31 
> cpu=5.43ms elapsed=159.56s tid=0x00007ff60c01da00 [0x00007000069c9000]
>    Carrying virtual thread #30
>         at 
> jdk.internal.vm.Continuation.run(java.base at 19-ea/Continuation.java:257)
>         at 
> java.lang.VirtualThread.runContinuation(java.base at 19-ea/VirtualThread.java:213)
>         at 
> java.lang.VirtualThread$$Lambda$21/0x000000080104da50.run(java.base at 19-ea/Unknown 
> Source)
>         at 
> java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(java.base at 19-ea/ForkJoinTask.java:1423)
>         at 
> java.util.concurrent.ForkJoinTask.doExec(java.base at 19-ea/ForkJoinTask.java:387)
>         at 
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 19-ea/ForkJoinPool.java:1311)
>         at 
> java.util.concurrent.ForkJoinPool.scan(java.base at 19-ea/ForkJoinPool.java:1840)
>         at 
> java.util.concurrent.ForkJoinPool.runWorker(java.base at 19-ea/ForkJoinPool.java:1806)
>         at 
> java.util.concurrent.ForkJoinWorkerThread.run(java.base at 19-ea/ForkJoinWorkerThread.java:177)
>
> Is it possible to get a stack trace of where that virtual thread #30 
> is at the moment?

Have you the new tried the new thread dump? There's an example in the 
"Observing virtual threads" section in the JEP.

-Alan


More information about the loom-dev mailing list