On Wed, 28 Jan 2026 11:51:06 GMT, David Holmes <[email protected]> wrote:
>> 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 has been
>> made 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.
>
> The `ThreadBlockInVM` is there so that a thread suspended before being
> notified does not expose that fact by issuing a monitor_waited event whilst
> suspended.
Moving `ThreadBlockInVM` outside will make it possible to suspend the successor
thread, which we don't want to happen. Getting rid of it completely will make
it possible, as David said, to post the waited event while being suspended,
which we also do not want to happen.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736447830
