New candidate JEP: 425: Virtual Threads (Preview)

[Remi Forax]

----- Original Message -----
> From: "Moataz Abdelnasser" <moataz.nasser20 at gmail.com>
> To: "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Saturday, April 9, 2022 7:24:45 AM
> Subject: Re: New candidate JEP: 425: Virtual Threads (Preview)

> Hi,

Hi Moataz,

> 
> 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?

I can answer to that question because i ask the same question to Ron :)

The first paragraph refers to the API, the API is not cooperative, as a user you do not have to explicitly hand back the control to the scheduler.
The second paragraph refers to the implementation, the code of the JDK, the virtual thread scheduler, is cooperative but as a user you do not have to care about that.

> 
> 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()`.

If you have a long-running CPU-intensive task available from a request, you may have DDos attak problems whatever the kind of threads you use because in both case you will exhaust the pool of available threads to serve the requests. And yes, a way to mitigate that issue is to use another pool of worker threads for those tasks and reject the request if this pool has no more threads.

> Otherwise, are there any plans to adopt a preemptive scheduler?

This question was already asked on this list so i'm parroting
"Not in the first release, maybe in the future, will see."

> 
> Cheers,
> Moataz

regards,
Rémi

> 
> 
> 
> 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