On Fri, 3 Jul 2026 05:29:53 GMT, David Holmes <[email protected]> wrote:
>> So even though this case has not been observed to fail we are now making it >> fail "just in case"? That seems wrong. >> >> I would consider it a perfectly legitimate debugging scenario to have a >> thread blocked on monitor entry, suspend it (as required) and call >> `StopThread` on it, and expect it to work. > > Also a virtual thread can't be blocked inside the JRT_ENTRY_NO_ASYNC. If the > monitor is not available the vthread has to return from that call to perform > the unmount operation that makes it act "blocked" until the monitor is > available. The problem we would hit here is that once we resume the thread we > would have to re-attempt the monitor acquisition and that will involve > executing "system" Java code that would then throw the exception. > > I'm just not seeing how this can possibly work - logically the user wants the > monitorenter to act as-if it were either preceded, or followed, by a "throw > exception". (For platform threads historically we only ever threw after, but > as you then immediately release the monitor again, you can't really make the > distinction - it acted as-if it happened before any try block in the > synchronized block/method.) But without a very sophisticated async-exception > deferral mechanism we can't stop it from hitting the core library code for > vthreads and breaking things. > So even though this case has not been observed to fail we are now making it > fail "just in case"? That seems wrong. Just to note that JVMTI StopThread minimally specifies that it can be used to "send an asynchronous exception to a virtual thread when it is suspended at an event. An implementation may support sending an asynchronous exception to a suspended virtual thread in other cases." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3523425774
