On Mon, 26 Jan 2026 14:45:34 GMT, Anton Artemov <[email protected]> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor 
>> (OM), then a following liveness issues can happen in the 
>> `ObjectMonitor::wait()` method.
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a 
>> suspension request, the thread will suspend itself whilst clearing the 
>> successor. The OM will be left unlocked (not grabbed by any thread), while 
>> the other threads are parked until a thread grabs the OM and the exits it. 
>> The suspended thread is on the entry-list and can be selected as a successor 
>> again. None of other threads can be woken up to grab the OM until the 
>> suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in three places where the successor could be suspended: 
>> 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> 3:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951
>> 
>> The issues are addressed by not allowing suspension in case 1, and by 
>> handling the suspension request at a later stage, after the thread has 
>> grabbed the OM in `reenter_internal()` in case 2. In case of a suspension 
>> request, the thread exits the OM and enters it again once resumed. 
>> 
>> Case 3 is handled by not transferring a thread to the `entry_list` in 
>> `notify_internal()` in case the corresponding JVMTI event is allowed. 
>> Instead, a tread is unparked and let run. Since it is not on the 
>> `entry_list`, it will not be chosen as a successor and it is no harm to 
>> suspend it if needed when posting the event. 
>> 
>> Possible issue of posting a `waited` event while still be suspended is 
>> addressed by adding a suspension check just before the posting of event.
>> 
>> Tests are added.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8366659: Addressed reviewer's comment.

A couple of nits but otherwise I think everything has been addressed and that 
the code will do what we want/expect.

Thanks

src/hotspot/share/runtime/objectMonitor.cpp line 2244:

> 2242:   assert(was_notified || state == ObjectWaiter::TS_RUN,
> 2243:     "was not notified and is not in the right state: was_notified = %s, 
> state = %s",
> 2244:     was_notified ? "true" : "false", node->getTStateName(state));

Suggestion:

  assert(was_notified || state == ObjectWaiter::TS_RUN,
         "was not notified and is not in the right state: was_notified = %s, 
state = %s",
         was_notified ? "true" : "false", node->getTStateName(state));

Fix indent.

Printing was_notified is redundant though as the assert can only fail if it is 
false.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3714312102
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2734592403

Reply via email to