Netty Support / VirtualThread Selector#select Issue

[Alex Otenko]

Selector per thread allows to spread the load across multiple threads. A
single selector either won't scale, or will waste cycles handing off work
to others.

But you want to keep the number of event loop threads close to #CPUs.
(Ideally equal to the number of cores, but it depends)

Alex

On Mon, 25 Oct 2021, 12:14 Johannes Schüth, <openjdk-loom-dev at jotschi.de>
wrote:

> Hello Alan,
>
> yes - there is one eventloop per thread. That's the default behavior for
> Netty. Your feedback gave me some clues on how to adapt the implementation.
> Using a single selector with multiple threads makes more sense.
> I'm not sure why Netty is using a different approach. Maybe this is done
> this way to avoid synchronization on selection key operations (which are
> not thread safe).
>
> Johannes
>
>
> Am Mo., 25. Okt. 2021 um 10:22 Uhr schrieb Alan Bateman <
> Alan.Bateman at oracle.com>:
>
> > 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.
> >
>