New candidate JEP: 425: Virtual Threads (Preview)

[Moataz Abdelnasser]

Hi,

Excellent document. I think it lays down most of what I want to know
about Loom (for now ;)).

However, aren't these two statements contradictory?

    "Virtual threads do not require or expect application code to
explicitly hand back control to the scheduler; in other words, virtual
threads are not cooperative)"

and

    "The scheduler does not currently implement time sharing for
virtual threads. Time sharing is the forceful preemption of a thread
that has consumed an allotted quantity of CPU time."

Shouldn't a non-preemptive scheduler be a cooperative one? Namely,
from what I understand, for a platform thread to be eligible for
sharing, the mounted virtual thread must cooperate (e.g. invoke one of
the blocking operations in
https://wiki.openjdk.java.net/display/loom/Blocking+Operations).
Shouldn't this make virtual threads cooperative, even if implicitly?

Also, doesn't this make it somewhat dangerous to run a CPU-bound task
in an Executors.newThreadPerTaskExecutor()? I can imagine a DoS attack
where a malicious client makes a server do some long-running
CPU-intensive task in virtual threads enough times that all FJP
parallelism is exhausted. Unlike OS threads, control never goes back
to carriers, denying servicing other clients. If my reasoning is
correct, shouldn't this make it necessary to explicitly caution
against CPU-bound tasks in virtual threads? Perhaps by recommending a
`var result = myFJP.submit(() -> doSomeCpuWork()).get()`. Otherwise,
are there any plans to adopt a preemptive scheduler?

Cheers,
Moataz



On Wed, Apr 6, 2022 at 6:15 PM <mark.reinhold at oracle.com> wrote:
>
> https://openjdk.java.net/jeps/425
>
>   Summary: Introduce virtual threads to the Java Platform. Virtual
>   threads are lightweight threads that dramatically reduce the effort
>   of writing, maintaining, and observing high-throughput concurrent
>   applications. This is a preview API.
>
> - Mark