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

Serguei Spitsyn sspitsyn at openjdk.org
Fri Nov 21 00:25:04 UTC 2025


On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern.

Yes, JVMTI event posting code performs thread state transitions. But I was talking about the JVMTI thread state bits specified here: https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetThreadState

> That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself.

Right. We have this oddity.

> Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

Right. There have to be some ways to fix it. Most likely we already have a bug against this issue.


> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the monitor_waited event would be posted whilst the thread is still suspended.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3560750605


More information about the serviceability-dev mailing list