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

[Anton Artemov]

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

I think this comment was supposed to be addressed to @sspitsyn

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWaitWorker.java line 42:
> 
>> 40: 
>> 41:     public void run() {
>> 42:         SuspendWithObjectMonitorWait1.logDebug("thread running");
> 
> SuspendWithObjectMonitorWaitBase instead of SuspendWithObjectMonitorWait1 here.
> There are a lot such places in this file.

Thanks for spotting this! Yes, `SuspendWithObjectMonitorWaitWorker` used to live in the same file as the original test and I forgot to update the names. Fixed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3556945962
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545160721