On Thu, 9 Jul 2026 22:52:17 GMT, David Holmes <[email protected]> wrote:
>> Not necessarily. The async exception will only be processed at the next >> safepoint poll that allows async exception processing. For `invokestatic`, >> if the call was already resolved before, there won’t be a poll (except for >> some possible VM call on method entry due to profiling). We would eventually >> process the async exception if we stay in the interpreter, because there is >> at least one poll at the return from `setState(YIELDING)`. But with compiled >> code and inlining that might not be even the case, so we could get to >> `startTransition` without any polls in between. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3555972710
