FJ parallelism zero

Doug Lea dl at cs.oswego.edu
Tue Aug 6 08:42:21 PDT 2013


Mostly to Brian, but other thoughts welcome:

As a compromise of sorts with the EE folks, we allow the
ForkJoinPool.commonPool to be set to parallelism zero
via a system property. We by default set to
Runtime.availableProcessors()-1.

All the Stream stuff can handle parallelism zero
(in these cases, the submitter ends up executing
all the subtasks).

But when the ForkJoinPool.commonPool is used for
purely async stuff, it is surprising at best that
tasks may never run unless somehow joined or the submitter
takes some alternative action (which we sometimes do in
other JDK usages of commonPool).

I think the EE folks are in general OK with the
surprise. But not so for those few people out
there running JDK8 on uniprocessors, with default
configurations, that also end up setting parallelism
to zero. So unless anyone can think of a reason
otherwise, I'm going to change to minimum parallelism
of one unless set to zero by system property.
(Brian: do you have any recollection of why we didn't
do it this way in the first place?)

-Doug


More information about the lambda-spec-observers mailing list