RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31]

Serguei Spitsyn sspitsyn at openjdk.org
Wed Jan 28 11:34:25 UTC 2026


On Wed, 28 Jan 2026 02:27:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time?
>> 
>> It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence:
>>  - suspend 1, resume 1, suspend 2
>> 
>> The `JvmtiExport::post_monitor_waited()` has a recursive call to `ThreadStateTransition::transition_from_native()` upon return from event callback. There is a suspend point there.
>> I'll read it more carefully and provide update if needed.
>
> IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension.

Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`.
As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point.
The problem here is a decision to post the monitor waited event at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point.

One approach would be to refactor this as below:

   // Process suspend requests now if any, before posting the event
   {
     ThreadBlockInVM tbvm(current, true);
   }
   if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) {
      JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT);

Another approach would be to get rid of this `ThreadBlockInVM`.
But it is hard to predict all the consequences.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736211365


More information about the serviceability-dev mailing list