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