effectiveness of jdk.virtualThreadScheduler.maxPoolSize
Alan Bateman
Alan.Bateman at oracle.com
Sat Jan 7 12:48:53 UTC 2023
On 06/01/2023 19:48, Robert Engels wrote:
> The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn’t happen.
Spinlocks are usually only used for locks that that are held for very
brief periods. If a virtual thread is doing I/O or running other code
that causes it to preempted while hold such a lock then yes, then
deadlocks like this could arise.
We expect that the maintainers of low level code with their own lock
implementations, or code doing spin waits to avoid parking, will need to
make some changes to work efficiently with virtual threads and with
greedy schedulers. Given that parking is cheap then it might be that
code goes straight to park when running in a virtual thread. For spin
locks it might be that it changes to be more hybrid so that it is
efficient when executed by both platform and virtual threads, and when
used together.
-Alan
More information about the loom-dev
mailing list