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

Stefan Karlsson stefank at openjdk.org
Fri Nov 10 13:25:59 UTC 2023


On Fri, 10 Nov 2023 12:54:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It still might eliminate locking due to the empty block.
>
> Yes, I agree with David. Look how other monitor inflation tests do this, we call `wait()` to guarantee both inflation (although it is partially handled by `LockingMode=0` here) and escaping to native call thus avoiding aggressive compiler opts.
>  https://github.com/openjdk/jdk/blob/6b21ff61dad6f633c744c1c33c29ea86183b509d/test/hotspot/jtreg/runtime/Monitor/DeflationIntervalsTest.java#L132-L140

Right, but currently it doesn't remove the synchronized block in my runs and this test was mainly added to be a very specific test that provokes the bug that this PR fixes. I previously considered adding a wait(1), but that will significantly limit the number of created monitors. Maybe I can add a counter inside the synchronized block, just like our JMH lock micros do?

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

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


More information about the hotspot-dev mailing list