Bug ID: JDK-6221510 GetAllStackTraces returns a JNI refs created in the wrong handle block

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b76Fixed

6213473 identified a number of JVMTI functions which create JNI refs incorrectly. These functions returned JNI refs that were created in a VM operation (and thus in the VM thread) but didn't using the handle block of the calling thread. 

This bug tracks other residual issues that also need to be fixed in JVMTI:

1. GetAllStackTraces returns a snapshot of all threads and their stacks. As per the contented/owned monitor functions in 6213473 this function returns JNI refs which are created in the VM thread but the handle block for the calling thread isn't used when creating the references.

2. GetThreadListStackTraces is provided with a thread list (array of jthread). These JNI refs are passed to the VM thread where they are resolved. As Bob pointed out JNI local refs are only valid in the thread in which they are created. In our implementation this shouldn't be an issue because the java thread is blocked waiting for the VM operation to complete so it should be okay to access JNI refs owned by the calling thread. However we should revisit this code and resolve the JNI refs in the calling thread before the VM operation is executed.
###@###.### 2005-1-25 21:51:38 GMT