RFR: 8301639: JDI and JDWP specs should clarify potential deadlock issues with method invocation

Alan Bateman alanb at openjdk.org
Wed Sep 13 13:04:42 UTC 2023


On Wed, 13 Sep 2023 01:07:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.se/share/data/jdwp/jdwp.spec line 1178:
>> 
>>> 1176:         "support the timer mechanism for virtual threads, and thus methods such as "
>>> 1177:         "<a href=../../api/java.base/java/lang/Thread.html#sleep(long)>Thread.sleep(long)</a> "
>>> 1178:         "may deadlock."
>> 
>> I think this is an implementation detail that you don't really want to document in these unrelated specifications. I'm also unclear why virtual threads are more of a problem here than regular threads, if you have suspended them all - a regular thread won't return from sleep until it is unsuspended. In fact the more I think about this, the less I see why virtual threads need special mention here at all.
>
> Of course as soon as I posted that I now realize the issue. There are more things that could "deadlock" virtual threads when all other threads are suspended - such as calling sleep, because it requires a "system" thread to be active. This suggest to me that we need modifications to JDWP/JDI to support effective debugging of virtual threads, by allowing for the notion of "system threads" that by default are not suspended (or else always resumed for an invoke).

A general point here is that there many cases that are unrelated to virtual threads where suspending all, except one, thread will deadlock/hang if other threads can't make progress. This includes several standard (java.*) APIs.

It is true that there are a couple of additional blocking operations with virtual threads that require I/O or timer threads to make progress in order to avoid a virtual thread being parked or blocked indefinitely. It feels more like something for  "@apiNote" for the invokeMethod/etc. javadoc, not clear to me that it's worth adding as a note in the description of the commands in the JDWP spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15695#discussion_r1324478823


More information about the serviceability-dev mailing list