On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer 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 Thr
On Wed, 7 Sep 2022 06:35:23 GMT, Chris Plummer wrote:
>> 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:
On Wed, 7 Sep 2022 05:55:56 GMT, Alan Bateman wrote:
> 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.
It was not some recent change in the de
On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer 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 Thr
On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer 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 Thr
On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer 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 Thr
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 bother
