Netty Support / VirtualThread Selector#select Issue

[Alan Bateman]

On 25/10/2021 06:02, Johannes Schüth wrote:
> Hello,
>
> I started some experiments on how to add Loom VirtualThread support to
> Netty.
>
> During my tests I noticed that Netty was no longer able to handle requests
> when using 500+ virtual threads for its reactor pool.
>
> I created a dedicated test without Netty to replicate this issue and found
> that the JVM would not run / start a new virtual thread if 400+ previous
> threads were calling new `Selector().select().`
> I'm not yet sure why this is the case. The thread dump shows all threads as
> 'Running'.
>
There are cases where the VM cannot suspend a virtual thread, we say 
that the thread is "pinned". One scenario (that we expect will go away 
in the long term) is when a virtual thread is holding a monitor. 
Blocking selection operations are one of these cases. Selector is 
specified to synchronize on the Selector object and can't be changed for 
compatibility reasons. So the summary that invoking blocking selection 
operations on a virtual thread will pin the thread for the duration of 
the selection operation. This means the underlying thread is not 
released to do other work. To compensate, parallelism will increase for 
the duration of the selection operations so you will see the number of 
carrier threads increase up to a limit (default is 256 but can be 
configured).

That said, I'm a bit surprised that you have a Selector per thread. That 
seems an architectural mismatch. Do you have an event loop per thread or 
how does this arise?

-Alan.