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

Serguei Spitsyn sspitsyn at openjdk.org
Wed Nov 19 19:11:02 UTC 2025


On Wed, 19 Nov 2025 04:55:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Added bool arg to notify_contended_enter
>
> Thank you for refactoring the test into several tests which share a common part. It is nice!
> May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

> @sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:
> Master branch, events posted: wait -> waited -> contended enter -> contended entered
> This PR: events posted: wait -> contended enter -> contended entered -> waited
> 
> I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of wait or not?

I also do not see anything in the specs (JLS, JVMS and JVMTI) but I feel it is better to keep the original order if possible.
It is going to be an impact/change on the thread state:
  https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetThreadState

AFAIU, with this change new combinations of thread state bits will be observable:
  `JVMTI_THREAD_STATE_WAITING` + `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`
  + (`JVMTI_THREAD_STATE_WAITING_INDEFINITELY` | `JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT`)

Also, it is a change in behavior with a compatibility risk involved. So, a CSR will be needed for this change.
I'm not sure yet if we need to consult with the JCK team on this if no JCK tests are failed.

What mach5 tests did you run? In this case, it is more safe to run mach5 tiers 1-6.
@dholmes-ora may have some concerns here.

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

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


More information about the serviceability-dev mailing list