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

[Daniel D. Daugherty]

On Wed, 12 Nov 2025 20:04:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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`.

Update: I figured this out. See the new doWork2 transaction diagram.

>> 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`.

Update: I figured this out. See the new doWork3 transaction diagram.

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

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