[concurrency-interest] Adding ForkJoinPool.setPoolSizeLimit

Doug Lea dl at cs.oswego.edu
Thu Jan 12 15:08:24 EST 2012

As I was just reminded, one benefit of FJP currently
NOT having dynamic configuration methods is that
different parts of a system all using the same FJP
cannot hurt each others usages by changing settings
in a way that only work well for one part. This
benefit seems worth preserving.

Which makes an alternative (once suggested by Viktor
and others) that doesn't expose control more attractive:

There already is a way to limit pool size: Use a
ForkJoinPool.ForkJoinWorkerThreadFactory that returns
null when it doesn't want to create additional
threads due to resource constraints. FJP copes
with null returns from ForkJoinWorkerThreadFactory.newThread,
and does so reasonably cheaply (which can/will be
made a bit cheaper still). Because the pool
is provided as an argument to newThread, the
factory can check the current size and state when
doing so.

For management and monitoring purposes this option
would be nicer if ForkJoinWorkerThreadFactory had
a second method
   void terminated(ForkJoinWorkerThread w)
that is invoked when a worker thread is terminated.
Only full termination seems possible -- we cannot reuse
these threads unless we change specs about
UncaughtExceptionHandlers, etc.
And anyway, creation/termination cycles tend to be long
enough in FJ that the extra bookkeeping necessary to reuse vs
recreate would rarely pay for itself.

Because ForkJoinWorkerThreadFactory is a nested
interface, doing this would be reasonably straightforward.
We could define:

public static interface ManagedForkJoinWorkerThreadFactory
   extends ForkJoinWorkerThreadFactory {
   void terminated(ForkJoinWorkerThread w);

And then add a few instanceof checks internally
to invoke terminated() if the provided factory
supports it.

If we take this option, then we should further consider
any other methods to add to this subinterface while we are
at it. Suggestions welcome.

Note though that even without a termination callback,
the existing mechanics above can minimally suffice (although
in a messier way), because of the opportunity for status probes
inside method newThread -- the main limitation is that these
queries can tell you only how many threads there are, but not
which threads are still alive.

Some replies:

On 01/12/12 09:57, √iktor Ҡlang wrote:

> 1) Should there be any possible backpressure for the FJP?

Do you have something in mind beyond the things I mentioned above?

> 2) What's the current behavior for submissions during shutdown?

The same as ThreadPoolExecutor. Upon shutdown, no new
submissions are accepted but existing tasks are processed
until the pool is quiescent, at which point it terminates.


More information about the Concurrency-interest mailing list