If JNI is used to lock an object and then all references to the object are dropped without the thread unlocking the object, then we have an in-use inflated ObjectMonitor whose associated object can be null due to it being GC'd.
Prior to the fix forJDK-8318757 encountering such a monitor would trigger an assertion. After that the null objects would be left in the array returned through GetOwnedMonitorInfo. This was considered risky to callers of the API so JDK-8320515 has changed that to filter them out.
It is not obvious that these monitors should be filtered out this way. If they are not then we have to look at clarifying the specification to reflect that array entries can be null. Code using the returned array will also have to be made aware that entries could be null. This could also impact JDI's ThreadReference.ownedMonitors API.
Prior to the fix for
It is not obvious that these monitors should be filtered out this way. If they are not then we have to look at clarifying the specification to reflect that array entries can be null. Code using the returned array will also have to be made aware that entries could be null. This could also impact JDI's ThreadReference.ownedMonitors API.
- relates to
-
JDK-8320515 assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object
- Resolved
-
JDK-8318757 VM_ThreadDump asserts in interleaved ObjectMonitor::deflate_monitor calls
- Closed