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

[Anton Artemov]

On Mon, 19 Jan 2026 01:19:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
>> 
>>  - 8366659: Fixed year in the copyright.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed ClearSuccOnSuspend
>>  - 8366659: Fixed liveness problem.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed build problem.
>>  - 8366659: Fixed build issue.
>>  - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed semi-broken tests
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1967:
> 
>> 1965:         // We can go to a safepoint at the end of this block. If we
>> 1966:         // do a thread dump during that safepoint, then this thread will show
>> 1967:         // as having "-locked" the monitor, but the OS and java.lang.Thread
> 
> To be clear, if it is a plain-old safepoint, we will show the monitor as locked because it is. But if it happens we were suspended, then we will release the monitor and so we wouldn't report locked.

I added clarification at the end of the comment.

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

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