Virtual Thread Scheduler - why ForkJoinPool?

[Florian Schmaus]

On 04/10/2022 17.57, Pedro Lamarão wrote:
> Em ter., 4 de out. de 2022 às 12:33, Florian Schmaus <flow at cs.fau.de 
> <mailto:flow at cs.fau.de>> escreveu:
> 
>     Basically, VirtualThread.submitRunContination() [1] submits the virtual
>     thread's continuation into the fork/join pool. This typically happens
>     when a virtual thread is unparked, e.g., when it became runnable again
>     after it was blocked on a synchronization primitive.
> 
>     Work-stealing scheduling is a perfect fit for concurrency platforms
>     like
>     Loom, and ForkJoinPool already implemented work-stealing. But I was not
>     the one who decided this, so please do not consider this an
>     authoritative answer.
> 
> 
> Is it not the case that a Continuation must always be resumed in the 
> same thread from where it was started?

I believe that is only true for pinned virtual threads, those have to be 
resumed on the carrier thread they ran on at the time they where parked. 
 From JEP 425 [1]

   There are two scenarios in which a virtual thread cannot be unmounted
   during blocking operations because it is pinned to its carrier:

   When it executes code inside a synchronized block or method, or
   When it executes a native method or a foreign function.


@Jonas: The Loom Proposal [2] has the following about ForkJoinPool:

Schedulers
As mentioned above, work-stealing schedulers like ForkJoinPools are 
particularly well-suited to scheduling threads that tend to block often 
and communicate over IO or with other threads. Fibers, however, will 
have pluggable schedulers, and users will be able to write their own 
ones (the SPI for a scheduler can be as simple as that of Executor). 
Based on prior experience, it is expected that ForkJoinPool in 
asynchronous mode can serve as an excellent default fiber scheduler for 
most uses, but we may want to explore one or two simpler designs, as 
well, such as a pinned-scheduler, that always schedules a given fiber to 
a specific kernel thread (which is assumed to be pinned to a processor).

Best Wishes
  Florian

1: https://openjdk.org/jeps/425
2: https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html