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

[Alan Bateman]

On Sat, 17 Jan 2026 16:11:35 GMT, Viktor Klang <vklang 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 641:
> 
>> 639:                 synchronized (timedWaitLock()) {
>> 640:                     byte seqNo = ++timedWaitSeqNo;
>> 641:                     timeoutTask = schedule(() -> waitTimeoutExpired(seqNo), timeout, MILLISECONDS);
> 
> Just a sidenote, I think it would be nice to see if we could eliminate the need for the seqNo if we were able to allocate the timeoutTask before submitting it, then using getAndSet or compareAndExchange to install it in the timeoutTask-field, and on cancellation we can CAS out it to null and only if we succeed we have successfully uninstalled it and can cancel it. Not high priority, but I find it valuable to always have an idea of how to do it differently. This might also make it possible to avoid having to use the timedWaitLock.

The seqNo is because the timeout task executes asynchronously, and can be executing when cancelled. It reduces the potential for interference and spurious wakeups when there is tight sequence of waits. There may be better designs, we went through when the changes were baking in the loom repo.

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

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