RFR: 8318757: VM_ThreadDump asserts in interleaved ObjectMonitor::deflate_monitor calls [v5]

[David Holmes]

On Thu, 9 Nov 2023 06:52:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.hpp line 135:
>> 
>>> 133: 
>>> 134:   // Iterate owned ObjectMonitors.
>>> 135:   static void owned_monitors_iterate(MonitorClosure* closure);
>> 
>> owned by whom? current thread? Does that include stack-locked or not?
>> 
>> Just trying to understand how the two variants of `owned_monitors_iterate` relate.
>
> Owned by *any* thread in any way.
> 
> * `owned_monitors_iterate(MonitorClosure* closure)` - Visits all monitors with the owner set to anything that indicates that the monitor has an owner (`ObjectMonitor::has_owner()`).
> 
> * `owned_monitors_iterate(MonitorClosure* m, JavaThread* thread)` - Visits all monitors with the owner field set to the specified `thread`.
> 
> Maybe we could figure out more descriptive names for these.

Updating the comment would be fine:

// Iterate ObjectMonitors owned by any thread.

Thanks

>> test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 78:
>> 
>>> 76:             monitors[index] = new Object();
>>> 77:             synchronized (monitors[index]) {
>>> 78:             }
>> 
>> I would expect C2 to eliminate this as well. The monitors are provably thread-local so synchronization is a no-op.
>
> Done

It still might eliminate locking due to the empty block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16519#discussion_r1388805691
PR Review Comment: https://git.openjdk.org/jdk/pull/16519#discussion_r1388807213