[External] : Re: Project Loom VirtualThreads hang

[Sam Pullara]

I think the biggest concern of completely moving to virtual threads is that
they don't fairly share the CPU when there are more than cores virtual
threads. This makes me hesitant to say they are the default.

On Thu, Jan 5, 2023 at 3:34 AM Ron Pressler <ron.pressler at oracle.com> wrote:

> The main thing I am trying to get across is not that virtual threads work
> best *only* when their number is high, but that the right way to adopt them
> is not to replace a platform thread with a virtual thread, but to represent
> some domain object (a request, a message etc.) with a virtual thread, and
> then, *as a result*, the number of virtual threads becomes a function of
> the load and will be high for systems under high load. This is particularly
> easy to do in very straightforward programs that don’t manually manage
> platform threads, and in these use-cases — where a virtual thread *doesn’t*
> replace a platform thread but some other object — we already match or
> exceed Go’s performance, especially when there’s some real work done.
> Adopting virtual threads in a useful manner in systems that depend on
> careful management of platform threads is harder.
>
> — Ron
>
> > On 5 Jan 2023, at 01:01, robert engels <rengels at ix.netcom.com> wrote:
> >
> > Understood. Thanks.
> >
> > For a large swath of “message systems” you are talking about hundreds of
> clients, not thousands, and certainly not millions. I am particularly
> referring to financial/trading systems.
> >
> > These usually use a fan-out structure so any given node only has < 100
> clients and often far smaller than that. Latency is a huge concern however.
> This can be done with async IO and native threads but it doesn’t “feel like
> Java” - and is certainly harder to understand/maintain in my opinion.
> >
> > If Loom allowed Go like performance it would be a killer solution for
> these “router” type nodes.
> >
> > But please don’t take this as a strong criticism -  in my testing Loom
> is within 10% of Go performance as it is today - which is a remarkable
> achievement especially given the backwards compatibility/programming model.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230105/7631ae12/attachment-0001.htm>