FJ parallelism zero

Doug Lea dl at cs.oswego.edu
Wed Aug 14 06:09:53 PDT 2013


On 08/12/13 13:03, Brian Goetz wrote:
> No recollection why we didn't do this in the first place!  In fact, I don't
> recall where the -1 came from.  The docs for FJP say:
>
>       * @param parallelism the parallelism level. For default value,
>       * use {@link java.lang.Runtime#availableProcessors}.

Not that it matters at this point since we are committing the
change, but the "-1" was done separately last fall to compensate
for the caller-runs changes in FJP. Without it, you can get
more threads working at any given time than cores -- the workers,
plus the caller. This is generally fine but suboptimal.
But should have still been floored at one to cover asyncs.

-Doug


>
> so I'd assumed that for single-core, we'd set to 1 and it would create a pool
> with (usually) one thread, and the zero option is "I really want no pool",
> mostly for those who have to be in control of all thread management (like EE
> containers.)
>
> On 8/6/2013 11:43 AM, Doug Lea wrote:
>> Oops. First posted without the "-libs"
>>
>> On 08/06/13 11:42, Doug Lea wrote:
>>> 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-libs-spec-observers mailing list