Virtual Threads are Better than ForkJoin Tasks That Block

[Brian Goetz]

This is a fair statement. While the FJ framework has gotten better over 
the years at dealing with tasks that block, it really shines in 
CPU-intensive, data-parallel applications.  Virtual threads shine where 
we have many tasks that are blocking most of the time.  (It wouldn't 
make sense to run a million virtual threads if they each wanted 50% of a 
CPU, but we can run a million virtual threads when they all spend most 
of their time blocking.)

You could make the same statement for parallel streams: "Virtual threads 
are better than parallel stream pipelines that block", because the 
split-vs-compute heuristics for streams are tuned for data-parallel, not 
blocking-parallel, workloads.

On 11/21/2021 2:43 PM, Eric Kolotyluk wrote:
> As I am trying to document my understanding of pre-loom and post-loom
> paradigms, am I correct in claiming
>
> *Virtual Threads are Better than ForkJoin Tasks That Block*
>
> Looking at ForkJoinTask
> <https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/ForkJoinTask.html>
> there is a lot of complexity around designing and implementing tasks that
> block. ForkJoin really seems better suited to things like Parallel Streams
> focused on computation.
>
> I am trying to create an informal list of problems that Project Loom
> solves...
>
> Cheers, Eric