[concurrency-interest] ForkJoinPool not designed for nested Java 8 streams.parallel().forEach( ... )

Doug Lea dl at cs.oswego.edu
Fri May 9 07:30:48 EDT 2014


On 05/08/2014 04:10 AM, Christian Fries wrote:
> Thank you for your reply. With respect to...
>
>> This does not in general do anything interesting beyond
>> making the task recursion stack shallower so that it becomes
>> less likely that nested joiners need compensation.
>
> ...I believe that the performance issue I am seeing is hard to be attributed to
> „less likely that nested joiners need compensation“

It is hard to believe but true. You might check some of this
(as I did) by running on machines with different numbers of
cores (and associated parallelism levels). The probability of
using uncompensated joins decreases with parallelism in this
(and some other) programs, because there are fewer ways that
workers can encounter joins but be unable to help process tasks.
In non-nested j.u.stream parallelism, streams use join-less
completion mechanics (the user-unfriendly CountedCompleter
form of ForkJoinTask that in part generalizes the much
friendlier CompletableFuture) such that they never hit this
problem. Currently, because nested parallelism uses two different
stream expressions, this technique is not used. Somehow
improving this state of affairs is on the todo list for JDK9.

In the mean time, if you need this usage to run fast,
you could try recasting it via the underlying CountedCompleter
mechanics. They are counter-intuitive to program, but we
put a lot of usage examples in the JavaDocs
(http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CountedCompleter.html). 


(Plain FJ join techniques are a lot easier to understand and use,
which is why we did not even initially provide public completion
based APIs. In general, concurrent programming techniques
that avoid blocking in any form are often the most efficient
but hardest to use. Although we are lucky that some forms,
like the fluent CompletableFuture API used with lambdas,
are user-friendly enough to avoid internal support
with occasionally surprising limitations like those seen here.

-Doug





More information about the Concurrency-interest mailing list