On Tue, 18 Aug 2026 20:18:25 GMT, Patricio Chilano Mateo <[email protected]> wrote:
>> Allow OpaqueFrameException for vthreads when suspended in a loop (not at an >> event). This became necessary after >> [JDK-8386116](https://bugs.openjdk.org/browse/JDK-8386116). The >> ThreadReference.stop() spec allows for this: >> >> `This method may 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.` >> >> and >> >> `OpaqueFrameException - if the thread is a suspended virtual thread and the >> implementation was unable to throw an asynchronous exception from the >> thread's current frame` >> >> I also field [JDK-8390483](https://bugs.openjdk.org/browse/JDK-8390483) to >> investigate if JVMTI should remove all vthread support for StopThread when >> not at an event rather than having work just some of the time. >> >> The failure used to happen about 1 out of 50 runs. Tested with both platform >> threads and with virtual threads about 200 times each with no issues. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line > 241: > >> 239: log.display("TEST #4: resuming thread."); >> 240: thrRef.resume(); >> 241: // Force the debuggee out of the loop. > > Any particular reason why removing that second part of the comment? Seems > that's still true. Because it is now needed if there is an OpaqueFrameException on a virtual thread. If this happens, there is no failure and we continue on to Test 5, but the debuggee would still be stuck in the loop in Test 4. > test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002t.java line > 144: > >> 142: stopMeHere++; stopMeHere--; >> 143: } >> 144: if (vthreadMode) { > > We could also restrict this case to when the debugger actually received > `OpaqueFrameException`. So you are worried about the case of no exception thrown on the debuggee side, but also no OpaqueFrameException on the debugger side. I'll need to add some additional communication between the debugger and debuggee. testNumReady is not sufficient, especially since the debugger does not ever write it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32403#discussion_r3808159665 PR Review Comment: https://git.openjdk.org/jdk/pull/32403#discussion_r3808221749
