On Fri, 28 Apr 2023 21:30:23 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> Note this PR depends on the #13546 PR for the following: >> >> [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of >> virtual threads to JVMTI StopThread >> >> So it can't be finalized and push until after JDK-8306434 is pushed. There >> will also be GHA failures until then. If JDK-8306434 results in any >> additional spec changes, they will likely impact this CR also. >> >> >> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some >> virtual thread support to JVMTI StopThread. This will allow JDWP >> ThreadReference.Stop and JDI ThreadReference.stop() to have the same level >> support for virtual threads. >> >> Mostly this is a spec update for JDWP and JDI, but there are also some minor >> changes needed to the ThreadReference.stop() handling of JDWP errors, and >> throwing the appropriate exceptions. Also some minor cleanup in jdb. The >> debug agent doesn't need changes since JVMTI errors are just passed through >> as the corresponding JDWP errors, and the code for this is already in place. >> These errors are not new nor need any special handling. >> >> Our existing testing for ThreadReference.stop() is fairly weak: >> >> - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a >> breakpoint. It will get problem listed by >> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for >> it already working and will push it separately. >> - nsk/jdi/stop/stop001, which is problem listed and only tests when the >> thread is blocked in Object.wait() >> - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception >> fails properly >> >> I decided to take stop002 and make it a more thorough test of >> ThreadReference.stop(). See the comment at the top for a list of what is >> tested. As for reviewing this test, it's probably best to look at it as a >> completely new test rather than looking at diffs since so much has been >> changed and added. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Some test logging improvements. src/java.se/share/data/jdwp/jdwp.spec line 2024: > 2022: (Error THREAD_NOT_SUSPENDED "The thread is a virtual thread > and was not suspended.") > 2023: (Error OPAQUE_FRAME "The thread is a suspended virtual > thread and the implementation " > 2024: "was unable to throw an asynchronous > exception from this frame.") Should it be aligned with JVMTI and some other places in your fix and say "from the current frame" instead of "from this frame"? src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 132: > 130: * @throws OpaqueFrameException if the thread is a suspended > 131: * virtual thread and the implementation was unable to throw an > 132: * asynchronous exception from this frame The same comment as for the jdwp spec: Should it be aligned with JVMTI and some other places in your fix and say "from the current frame" instead of "from this frame"? src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java line 279: > 277: case JDWP.Error.OPAQUE_FRAME: > 278: assert isVirtual(); // can only happen with virtual > threads > 279: throw new OpaqueFrameException(); Should the OpaqueFrameException also provide a message? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1182950871 PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1182951575 PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1182954262
