On Wed, 13 Sep 2023 01:07:58 GMT, David Holmes <dhol...@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
