On Fri, 10 Jul 2026 02:16:41 GMT, David Holmes <[email protected]> wrote:
>> I'm not at all convinced that we can get through the initial call and: >> >> public static void yield(); >> descriptor: ()V >> flags: (0x0009) ACC_PUBLIC, ACC_STATIC >> Code: >> stack=1, locals=2, args_size=0 >> 0: invokestatic #19 // Method >> currentThread:()Ljava/lang/Thread; >> 3: astore_1 >> 4: aload_1 >> 5: instanceof #59 // class >> java/lang/VirtualThread >> 8: ifeq 23 >> 11: aload_1 >> 12: checkcast #59 // class >> java/lang/VirtualThread >> 15: astore_0 >> 16: aload_0 >> 17: invokevirtual #61 // Method >> java/lang/VirtualThread.tryYield:()V >> 20: goto 26 >> 23: invokestatic #65 // Method yield0:()V >> 26: return >> >> without hitting an async-exception polling point. But this does highlight >> just how difficult it is to determine, for any given code sequence, where >> such a point might exist. >> >> I'm starting to think that in relation to `StopThread` we should be checking >> for this "async exception" in the same places that we would be checking for >> a JVM TI suspension request. Not something to dwell on for this PR of course. > > Note that any native method call will check for suspend and asyncs on its > return. Yes, but if you mention it because of the call to `currentThread`, note that method is intrinsified, even in the interpreter. If we stay in the interpreter, we would eventually process the async exception before the call to `startTransition`, due to the polls on method return (`setState(YIELDING)`) and when a branch is taken (following the bytecodes generated by javac I see one case at the beginning of `tryYield`). But as mentioned before, with compiled code and inlining, there might not be any polls at all, so we could get to the same reported crash. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3571918913
