On Mon, 24 Nov 2025 01:32:19 GMT, David Holmes <[email protected]> wrote:
>>> 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. @dholmes-ora @sspitsyn Please take a look, I have re-worked a bit the logic with a hint from @pchilano. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3728629333
