[External] : Re: Project Loom VirtualThreads hang

[thurston N]

"It is not hard to add time-sharing to virtual threads"

If so, how hard would it be to add *user-directed timesharing*. e.g.

VirtualThreads.yield(reschedule=LOW_PRIORITY) // a strong hint to scheduler
to run other Continuations (that's other continuations not just other
"tasks") before resuming current continuation

I don't know if that ameliorates Sam's specific situation or not, but it's
not difficult to think of many circumstances that could benefit from such
an ability.
One of the core ideas of coroutines is cooperative multitasking, now I
suppose one could rejoin with CONTINUATIONS ARE NOT COROUTINES, but so
what? what's wrong with cooperative-multitasking continuations?

It's one thing not to have automated timesharing built into the scheduler
(which I would think would be difficult to do well, but IDK), it's quite
another to afford no opportunity for user-level  code to "control the
scheduling" (how about "influence" or "affect" vis a vis "control"?)

This strikes me as a bit of a circular argument, viz. if your target/focus
is workloads with a lot of *short-lived* tasks, then yeah, it's going to be
difficult to conjure scenarios where automated timesharing will make any
difference (in the extreme case where every task runs shorter than its
allotted time quantum, then time-slicing can make no difference at all)


-T


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/25ace828/attachment.htm>