On Thu, 9 Jul 2026 19:52:13 GMT, Patricio Chilano Mateo
<[email protected]> wrote:
>> But a call to `Thread.yield` would consist of executing many bytecodes and
>> we should be processing the async-exception at the first of those - ie the
>> invokestatic - is that not the case?
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3555299415
