RFR: 8373120: Virtual thread stuck in BLOCKED state [v2]

Patricio Chilano Mateo pchilanomate at openjdk.org
Fri Jan 16 17:12:21 UTC 2026


On Fri, 16 Jan 2026 13:37:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comment in test
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 644:
> 
>> 642:                     setState(newState = TIMED_WAIT);
>> 643:                     // May have been notified while in transition. This must be done while
>> 644:                     // holding the monitor to avoid changing the state of a new timed wait call.
> 
> "to avoid changing the state of a new timed wait call". It might be clearer to say move to the blocked state before the timeout task can execute.

I wanted to keep it more general because the thread can also run again due to notification+unblock or interruption.

> test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77:
> 
>> 75:             }
>> 76:         });
>> 77:         var pthread = Thread.ofPlatform().start(() -> {
> 
> A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment.

Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2699306583
PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2699307350


More information about the core-libs-dev mailing list