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