RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread [v3]

Richard Reingruber rrich at openjdk.org
Thu Feb 1 09:22:02 UTC 2024


On Thu, 1 Feb 2024 06:56:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> There is definitely an issue with `ObjectMonitor::enter`. The extended test I added is currently failing with LM_MONITOR. The issue is that the the call to `ObjectMonitor::enter` races with deflation (seems like the monitorinflation trace logging made this race much more likely to happen) . But `ObjectMonitor::enter` asserts that `assert(current->thread_state() != _thread_blocked, "invariant");` before checking for deflation . And because the thread is suspended it is obviously also blocked. (Also seeing a timeout on windows-x64-debug, have to investigate if it is the same cause, it is also with LM_MONITOR)

Good catch. I think that can really only happen with LM_MONITOR (things where different at the time of JDK-8227745).

> Given this I believe that it might be the only tenable solution that we restrict the normal `enter` to only the `current` thread and create a new `enter_for` exclusively used by the re-lock code for both ObjectSynchronizer and ObjectMonitor.

I think you could also return false in `ObjectMonitor::enter()` [about here](https://github.com/openjdk/jdk/blob/68206b533b09e07e4d556df794414ed4538889c0/src/hotspot/share/runtime/objectMonitor.cpp#L337) if the locking thread is not the current thread. The caller `ObjectSynchronizer::enter()` would then allocate a new monitor and retry.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920865433


More information about the hotspot-dev mailing list