JDK-8320721 : JVMTI GetOwnedMonitorInfo needs to be aware that JNI Locked Monitors can be associated with a dead (null) object
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 22
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-11-27
  • Updated: 2024-04-04
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8318757 - VM_ThreadDump asserts in interleaved ObjectMonitor::deflate_monitor calls
Relates :  
JDK-8320515 - assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object
Description
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 for JDK-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.