RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object

[Stefan Karlsson]

On Thu, 23 Nov 2023 02:07:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump asserts in interleaved ObjectMonitor::deflate_monitor calls`
>> 
>> I removed the filtering of *owned ObjectMonitors with dead objects*. The reasoning was that you should never have an owned ObjectMonitor with a dead object. I added an assert to check this assumption. It turns out that the assumption was wrong *if* you use JNI to call MonitorEnter and then remove all references to the locked object.
>> 
>> The provided tests provoke this assert form:
>> * the JNI thread detach code
>> * thread dumping with locked monitors, and
>> * the JVMTI GetOwnedMonitorInfo API.
>> 
>> While investigating this we've found that the thread detach code becomes more correct when this filter was removed. Previously, the locked monitors never got unlocked because the ObjectMonitor iterator never exposed these monitors to the JNI detach code that unlocks the thread's monitors. That bug caused an ObjectMonitor leak. So, for this case I'm leaving these ObjectMonitors unfiltered so that we don't reintroduce the leak.
>> 
>> The thread dumping case doesn't tolerate ObjectMonitor with dead objects, so I'm filtering those in the closure that collects ObjectMonitor. Side note: We have discussions about ways to completely rewrite this by letting each thread have thread-local information about JNI held locks. If we have this we could probably throw away the entire ObjectMonitorDump hashtable, and its walk of the `_in_use_list.`.
>> 
>> For GetOwnedMonitorInfo it is unclear if we should expose these weird ObjectMonitor. If we do, then the users can detect that a thread holds a lock with a dead object, and the code will return NULL as one of the "owned monitors" returned. I don't think that's a good idea, so I'm filtering out these ObjectMonitor for those calls.
>> 
>> Test: the written tests with and without the fix. Tier1-Tier3, so far.
>
> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 59:
> 
>> 57:         // GetOwnedMonitorInfo testing.
>> 58:         Object obj = new Object() { public String toString() {return "";} };
>> 59:         jniMonitorEnter(obj);
> 
> I would add a check for `Thread.holdsLock(obj);` after this just to be sure it worked.

Done

> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 61:
> 
>> 59:         jniMonitorEnter(obj);
>> 60:         obj = null;
>> 61:         System.gc();
> 
> Again one gc() is generally not sufficient.
> 
> How can this test tell that the object in the monitor was actually cleared? I think `monitorinflation` logging may be the only way to tell.

Yes, probably. I've been looking at the `monitorinflation` logging to very that it gets cleared. I think it would be messy to try to get this test to also start to parse logs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16783#discussion_r1403245976
PR Review Comment: https://git.openjdk.org/jdk/pull/16783#discussion_r1403244666