RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v9]

[Daniel D. Daugherty]

On Fri, 16 Jan 2026 21:50:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1950:
>> 
>>> 1948:         // as having "-locked" the monitor, but the OS and java.lang.Thread
>>> 1949:         // states will still report that the thread is blocked trying to
>>> 1950:         // acquire it.
>> 
>> Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). @dcubed-ojdk, could you comment on this, please?
>
> Sorry for the long delay in getting back to this review.
> 
> Hmmmm... I'm wondering if that comment is correct:
> - We've creat `ExitOnSuspend eos` on L1961.
> - We create `ThreadBlockInVMPreprocess` on L1963 AND we pass `eos`.
> - We reenter the monitor on L1964.
> - When we run the `ThreadBlockInVMPreprocess` destructor on L1972 below:
>    - We call the `eos` object on the current thread BEFORE we `call process_if_requested`
> 
> So it looks to me like we exit the monitor before we block for the safepoint so we should not
> be showing the monitor as "locked" by our "blocked" thread.

I think the comment addition on L1974-1976 addresses this review thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2742799060