Project Loom VirtualThreads hang

Alan Bateman Alan.Bateman at oracle.com
Wed Dec 28 08:58:52 UTC 2022


On 28/12/2022 01:28, Eric Kolotyluk wrote:
>
> My 2 cents...
>
> Right, Virtual Threads are not preemptable, and as explained by Ron 
> previously, it would be hard to make them preemptable...
>
> If a thread spins, this can be a problem, I don't know that "all other 
> threads will be blocked." Not sure why it's assumed that fork-join is 
> not stealing work...
>
> My intuition would be that Thread.yield() should move the current 
> thread to the end of the run queue, as I have often used this in the 
> past to serialize operations and achieve similar effects. If it does 
> not move the current thread to the end of the queue, I would love to 
> know why.
>
There isn't a single "run queue". The scheduler is a ForkJoinPool with 
submission queues, and task queues for each worker (carrier) thread. In 
JDK 19, the implementation of virtual Thread.yield always pushes to the 
current carrier thread's task queue, and in a lazy manner to reduce 
steals. It has changed in JDK 20 so that it pushes to a submission queue 
when the current carrier thread's task queue is empty. This should 
improve fairness and reduce surprises, but the temptation to assume it 
can be used to get cooperative scheduling should be avoided.

I haven't looked at the reproducer but I see Alex Otenko's mails 
suggesting that the ring buffer has other issues. Once they are fixed 
then it would be interesting to re-run the test with JDK 20 to see if 
that changes the behavior.

-Alan.


More information about the loom-dev mailing list