Fibers for ForkJoinPools

[Ron Pressler]

I am not entirely sure I understand you question, but I’ll try to address it as much as I can.

The default fiber scheduler uses FJPool by default to schedule the fibers’ internal
continuations. Using a work-stealing scheduler for fibers makes sense because they
are assumed to be in frequent communication with one another, and work-stealing gives
rise to better data locality. FJPool may well change a little bit to perform this task better.

However, today’s uses of FJ, either with parallel streams or directly, are mainly for 
parallelism, whereas fibers are mostly aimed to tackle concurrency and meant more
for transaction processing than heavy computation.

There are no current plans to employ continuations internally for FJ’s join operations,
if only because we don’t yet know the overhead continuations incur, as the implementation
is still very fluid; when we do, what may be OK for IO, may not be OK for fine-grained
parallelism. However, FJ could probably make good use of tail-call elimination, which
we intend to get around to once fibers/continuations are released.

Ron

On July 22, 2019 at 10:19:29 AM, Olivier Peyrusse (kineolyan at gmail.com) wrote:

Hello everyone,  

is there any plans to make the ForkJoin framework evolve with the  
introduction of continuations?  
One part of the ForkJoin framework uses RecursiveAction or RecursiveTask,  
that perform a simple fork-then-join. Other implementations like Cilk in  
C++ considered doing continuations as a solution after the join, while the  
FJ framework is currently based on work stealing.  
Having continuation may also simplify the writing of CountedCompleters, for  
they are already objects representing continuations.  

I guess they are no immediate easy solution to make both continuations and  
work-stealing play together. But I was wondering if some work was scheduled  
about this topic.  

Thanks  
Olivier