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
- 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
-