On Mon, 26 Jan 2026 23:56:03 GMT, Serguei Spitsyn <[email protected]> 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
