RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31]
David Holmes
dholmes at openjdk.org
Thu Jan 29 01:42:32 UTC 2026
On Wed, 28 Jan 2026 21:30:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled.
>
>> Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled.
>
> Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled.
> Update: I see your point. You most likely suggested something like this:
>
> if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) {
> // Process suspend requests now if any, before posting the event
> {
> ThreadBlockInVM tbvm(current, true);
> }
> // Re-check the condition as the monitor waited events can be disabled whilst thread was suspended.
> if (JvmtiExport::should_post_monitor_waited()) {
> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT);
> }
Yes that is what I meant. The event could have been disabled since the notification, in which case we don't need to bother with the TBIVM etc.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2739379031
More information about the serviceability-dev
mailing list