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

[David Holmes]

On Mon, 26 Jan 2026 23:56:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I may not fully understand the problem here, but isn't it that suspension requests will be processed in order of execution at relevant places in the code? 
>> 
>> If there are, for instance 2 of those, then n1 will be handled on L1939, n2 - inside of `JvmtiExport::post_monitor_waited()`, any further suspension request will be handled by the thread as soon as it runs into a check for suspension in the program flow. What exactly is the concern here? There is no harm to suspend the thread in both L1939 and L1942 as the thread is known not to be the successor.
>> 
>> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time?
>
>> @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.

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

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