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

Doug Lea dl at cs.oswego.edu
Tue May 6 12:52:41 EDT 2014


On 05/06/2014 08:34 AM, √iktor Ҡlang wrote:
>
>   In versions prior to JDK7 release, continuation-thread
>     compensation generated spare threads to maintain target parallelism.
>     This works great for correctly expressed nested parallelism but is
>     prone to positive feedback loops when people make small design errors
>     like inverting joins. When mixed with blocking IO, we saw cases where
>     this generated thousands of threads. So for the sake of JVM stability,
>     compensation is restricted to cases where the pool is saturated. This
>     could be re-explored.
>
>
> Speaking of which—is there anything that prevents adding the capability to
> specify the maximum number of threads allowed to be spawned due to managed
> blocking? (The current default blows up about every JVM there is.)

The current default is to only generate a new thread if saturated,
which is the most conservative possible policy. If we allowed a
bound on compensations, then everything could freeze up if past
some arbitrary limit, which seems even less popular than risking
OutOfMemoryError (and RejectedExecutionException) thrown by
attempted Thread construction. Especially since you can use
ForkJoinWorkerThreadFactories and/or SecurityManagers or to bound
the total number of Threads in a program, whether by FJ or elsewhere.

-Doug





More information about the Concurrency-interest mailing list