On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer <cjplum...@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
