RFR: 8373120: Virtual thread stuck in BLOCKED state

[David Holmes]

On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS.
> 
> The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call.
> 
> The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman.
> 
> Thanks,
> Patricio

@pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized.

It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK?

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

PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3757721807