RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension request [v17]

[David Holmes]

On Fri, 21 Nov 2025 11:38:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks @sspitsyn for diving into the issue. 
>> 
>> With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?
>
>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?
> 
> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

@sspitsyn  so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes?

We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing. The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress.

Agreed the tests are completely artificial but there is no way to test this other than to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3568649410