[External] : Re: Project Loom VirtualThreads hang

[Sam Pullara]

So the place where this comes up is when you do a short computation but use
tons of threads to do it. Like, for example, I have a brute force embedding
search library that uses parallel streams to do the query. If that takes a
few seconds (or even hundreds of ms) I still want other threads doing more
mundane, fast work to get CPU time rather than every other computation on
the system being blocked.

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

>
>
> > On 5 Jan 2023, at 18:01, Sam Pullara <spullara at gmail.com> wrote:
> >
> > 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.
>
> Note that existing Java servers also don’t rely on time-sharing even when
> using platform threads. Non-realtime kernels usually only employ
> time-sharing when the CPU is at 100%. I think that the vast majority of
> Java servers don’t run at 100% CPU utilisation, and when they do, I don’t
> think anyone is particularly happy with the result. In fact, the scheduling
> offered by fixed thread pools that are commonly used in thread-per-request
> servers is far *less* “fair”, or shared, than virtual threads.
>
> It is not hard to add time-sharing to virtual threads, it’s just that I
> think people have an incorrect impression of how useful time-sharing is for
> server workloads. BTW, even parallel streams, which are designed for
> CPU-bound workloads, don’t offer time-sharing. Asynchronous constructs in
> the JDK or Java libraries don’t offer time-sharing, either.
>
> We would gladly consider adding time-sharing to virtual threads if anyone
> finds reasonable workloads where it actually helps considerably. I’m not
> saying there aren’t any, it’s just that we haven’t seen them yet. Perhaps
> wider use of virtual threads in the field will expose some.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230105/66ce7b10/attachment.htm>