On Wed, 13 Sep 2023 13:01:32 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> 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. I can change it to `@apiNote`. Since it is not really part of the spec, I can see leaving it out of the JDWP spec. It's mostly important to get this info to JDI users. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15695#discussion_r1324751119
