[concurrency-interest] Advice on reuse of ForkJoinTask instances

Doug Lea dl at cs.oswego.edu
Tue Mar 20 06:47:04 EDT 2012

On 03/19/12 12:52, √iktor Ҡlang wrote:
> We're using the latest incarnation of the ForkJoinPool in Akka,
> and I was looking at reducing allocations in the hot path, and essentially the
> only thing left to remove is to remove the creation of a FJT for every
> submission (and we have _lots_ of those), but unfortunately it seems rather
> non-straightforward as I'll have to call reinitialize at the end of executing
> the FJT.

There are a few common cases where it is easy and effective
to reuse FJTs, for example when building trees of recurring
computations. (The FJJacobi program in our CVS src/tests/loops
has one example.) But in most other cases, GC will do a better
job of managing space than you can. FJ is extremely friendly
to generational collectors -- most tasks become garbage and
reclaimable almost immediately, and managing the others is done
better using GC mechanics than almost anything else you could do.

Usually a better tactic is to minimize any auxiliary object
creation needed to start or process a task. Often enough,
these other objects are less GC-friendly. Among other steps,
it is usually worthwhile to "flatten" tasks so that they
contain all necessary state for execution without creating other
transient objects. For example, in graph algorithms, it often
works nicely to make each node itself a ForkJoinTask.


More information about the Concurrency-interest mailing list