RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() [v4]

[Serguei Spitsyn]

On Fri, 28 Apr 2023 21:30:23 GMT, Chris Plummer <cjplummer at 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