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

[Daniel D. Daugherty]

On Tue, 18 Nov 2025 00:39:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Addressed reviewer's comments.
>
> 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.

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

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