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 16:55:39 UTC 2022
On 20/06/2022 17:16, Dr Heinz M. Kabutz wrote:
> Hi Ron and Alan,
>
> I was pondering today what would happen if two virtual threads
> deadlocked, either on synchronized or on ReentrantLock. My intuition
> was that if it was on a ReentrantLock, then those two virtual threads
> would be effectively decommissioned, and that they would not use up
> any carrier threads, but that if they were deadlocking on
> synchronized, that the carrier threads would be permanently blocked.
> This appears to be the case, however, due to RFR 8285196 I'm
> struggling to see how we could discover something like this. We'd just
> notice (or not) that there are less carrier threads available. Of
> course we could dig in further and dump all the virtual threads,
> hoping to discover the deadlock, but the tool of the ThreadMXBean does
> not seem to be available anymore.
There isn't any API or tooling support for reporting deadlocks involving
virtual threads at this time. This goes for both monitors and ownable
synchronizers. The ThreadMXBean API doesn't scale for virtual threads
which is why it is specified to only support the monitoring and
management of platform threads. Deadlock cycles that include virtual
threads had to be spec'ed out as otherwise the API would be
inconsistent. This is something we have to come back to, it's just not
there at this time.
-Alan.
More information about the loom-dev
mailing list