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

[eric at kolotyluk.net]

As someone who has used Java deadlock detection in the past, I wanted to affirm that it can be very valuable at times, critical in fact, especially when inheriting smelly spaghetti code...

Hats off to Dr. Kabutz for raising the issue... and to Alan Bateman for acknowledging this is on the TODO list...

Cheers, Eric

-----Original Message-----
From: loom-dev <loom-dev-retn at openjdk.org> On Behalf Of Alan Bateman
Sent: June 20, 2022 9:56 AM
To: Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Cc: loom-dev <loom-dev at openjdk.java.net>
Subject: Re: Deadlocks in virtual threads - was RFR: 8285196: Deadlock reporting prints carrier thread when virtual thread is in deadlock cycle

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.