Fibers for ForkJoinPools

[Olivier Peyrusse]

Hello Ron,

I think you got it very well.
I was thinking that the following pseudo-code could use the concept of
continuation:
void method() {
  var taskA = <some task>;
  var taskB = <other task>;
  taskA.fork();
  taskB.exec();
  taskA.join(); // Here, we could have created a continuation, to trigger
the execution of process once taskA joined
  process(taskA, taskB);
}
But your answer completely makes sense. Project Loom is focusing on IO more
than using this mechanism for intensive computation.

So thanks for your answer and the good work. I am waiting for its release
to see it perform.

Best regards

[1] https://wiki.openjdk.java.net/display/loom/Structured+Concurrency

Le lun. 22 juil. 2019 à 17:46, Ron Pressler <ron.pressler at oracle.com> a
écrit :

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