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