###@###.### 2003-06-19

Older versions of jdbx used to have a debugger agent thread that operated
on behalf of another thread. However, that only works using the product
VM. The debug VM has assertions that fail when this type of behavior is
tried. A work around was put in place in the Ladybird (1.3.1) release
that allowed the product mode bits to continue working:

4432884 1/2 jdbx does not work with jdk 1.3.1 starting with rc1 build
            19 onwards

I broke the workaround in Hopper-B06 with some of my suspend/resume
changes. The work around was restored with the following bug fix:

4657650 3/5 threadstart002: suspend/resume fails with intermediate
            DeleteGlobalRef call

The old behavior of jdbx is wrong as shown by the following docs:

> From: Jim Holmlund <###@###.###>
> Date: Fri, 12 Apr 2002 18:52:03 -0700 (PDT)
> Subject: Re: need opinion on 4657650
>
> It seems to also be the opinion of the JNI spec; see the last sentence
> of section 11.5.1 here
> http://java.sun.com/docs/books/jni/html/design.html#8371
>
> and section 8.1.1 here:
> http://java.sun.com/docs/books/jni/html/other.html#29362

These two sections explicitly rule out making a JNI call with another
thread's JNIEnv.

We have carried around the workaround for many releases and it
continues to cause confusion. We even have an NSK test that verifies
that the workaround is still in place:

    nsk/jvmdi/events/threadstart002

The purpose of this bug report is to track the process of removing the
workaround from the VM. Once this is done, threadstart002 will fail
in both product mode and debug mode.