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

[Daniel D. Daugherty]

On Wed, 12 Nov 2025 17:36:44 GMT, Daniel D. Daugherty <dcubed 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 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:
> 
>> 370:                 // - a threadLock enter in the resumer thread
>> 371:                 // - resumption of the waiter thread
>> 372:                 // - a threadLock enter in the freshly resumed waiter thread
> 
> This list of step tests is identical to the list on L490 -> L493 and the
> original llist on L256 -> L259.
> 
> This step comment:
> `370:               // - a threadLock enter in the resumer thread`
> should be updated to something like:
> 
>              // - a blocked threadLock enter in the resumer thread while the
>              //   threadLock is held by the main thread.
> 
> 
> This change of threadLock scope also requires this update from:
> 
> 605:        // - tries to grab the threadLock (should not block!)
> 
> 
> to:
> 
> 605:        // - tries to grab the threadLock (should not block with doWork1!)

I can't figure out why we're delaying the resumer thread in `doWork2`.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:
> 
>> 491:                 // - a threadLock enter in the resumer thread
>> 492:                 // - resumption of the waiter thread
>> 493:                 // - a threadLock enter in the freshly resumed waiter thread
> 
> This list of step tests is identical to the list on L369 -> L372 and the
> original llist on L256 -> L259.
> 
> This step comment:
> 
> 491:               // - a threadLock enter in the resumer thread
> 
> should be updated to something like:
> 
>              // - a blocked threadLock enter in the resumer thread while the
>              //   threadLock is held by the main thread.

I can't figure out why we're delaying the resumer thread in `doWork3`.

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

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