On Fri, 3 Jul 2026 05:13:20 GMT, David Holmes <[email protected]> wrote:
>> The monitorenter VM call is `JRT_ENTRY_NO_ASYNC`, meaning we don’t process >> asynchronous exceptions on the way back to Java. This patch restricts >> installing asynchronous exceptions for virtual threads blocked there as we >> cannot guarantee when they will be thrown. This test is exercising that case >> so returning `JVMTI_ERROR_OPAQUE_FRAME` makes it fail. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3517663079
