P4 Backports
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2176769 | 7 | David Holmes | P3 | Closed | Fixed | b03 |
| JDK-2171836 | 6u4 | David Holmes | P3 | Closed | Fixed | b03 |
Description
There is a general requirement that native methods calling in to the VM set the correct thread state when doing so - normally thread_in_vm. There is one path through the JNI direct buffer support initialization code that does not do this however. This leads to the thread being in state _thread_in_native instead of _thread_in_vm. A recent change to the os:sleep code (see CR 6459874) enabled a ThreadBlockInVM transition object that, in debug mode, enforces that the thread is in the state _thread_in_vm. As this is not the case then the assertion fails at runtime. Being in the wrong state is actually benign in terms of functionality. Further there has to be an initialization race between multiple threads for the os::sleep call to actually get executed.
Attachments
Issue Links
- backported by
-
JDK-2171836 JNI Direct Buffer API calls don't set the correct thread state during initialization
-
- Closed
-
-
-
- Closed
-
- relates to
-
JDK-6852404 Race condition in JNI Direct Buffer access and creation routines
-
- Closed
-
-
-
- Closed
-