RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes

[Alan Bateman]

On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD.
> 
> In the JDWP spec I change the description of THREAD_NOT_ALIVE  to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better.
> 
> In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended.
> 
> Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work.

src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java line 600:

> 598:             case JDWP.Error.THREAD_NOT_ALIVE:
> 599:                 throw new IncompatibleThreadStateException(
> 600:                                      "Thread has not started or has finished");

When doing anything here we have to take into account that the debugger (or JDI tool) may be connected to a target VM on an older or newer release. So if I read the issue correctly, the reply to the ThreadReference/ForceEarlyReturn command never returned THREAD_NOT_ALIVE so it's okay to remove the mapping to IncompatibleThreadStateException.

-------------

PR: https://git.openjdk.org/jdk/pull/10189