Description
JNI spec states that all Java monitors held by thread are released after call of DetachCurrentThread. Test (see attachment) shows that it isn't correct.
PS Wow, but jrockit works fine.
###@###.### 2005-06-08 13:00:11 GMT
DetachCurrentThread also doesn't free local variables from java frames in thread stack. These frames are unreacheable but GC doesn't collect them until native thread is finished.
###@###.### 2005-06-09 14:51:06 GMT
I'm sorry, i had attached incorrect test case sources. Updated source is correct (no DetachCurrentThread failures).
Moreover, IBM VM have the same problem as a hotspot. but jrockit still correct one!
###@###.### 2005-06-22 13:30:51 GMT
PS Wow, but jrockit works fine.
###@###.### 2005-06-08 13:00:11 GMT
DetachCurrentThread also doesn't free local variables from java frames in thread stack. These frames are unreacheable but GC doesn't collect them until native thread is finished.
###@###.### 2005-06-09 14:51:06 GMT
I'm sorry, i had attached incorrect test case sources. Updated source is correct (no DetachCurrentThread failures).
Moreover, IBM VM have the same problem as a hotspot. but jrockit still correct one!
###@###.### 2005-06-22 13:30:51 GMT
Attachments
Issue Links
- relates to
-
JDK-6448027 com.sun.jdi.ThreadReference.ownedMonitorsAndFrames() returns unexpected monitor
- Closed
-
JDK-6289830 Monitors entered by JNI MonitorEnter aren't freed after thread quits normally
- Closed
-
JDK-6336479 DetachCurrentThread should release thread-owned monitors
- Closed
-
JDK-6219874 JNI document should say to invoke "DetachCurrentThread()" on thread exit
- Closed