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