[concurrency-interest] Fork/Join traces: instrumentation and rendering

Doug Lea dl at cs.oswego.edu
Sun Jun 10 17:10:19 EDT 2012

> One thing it makes me wonder is, if the FJP is executing some slow tasks
> and a number of joiners are waiting on them, and then another task is
> submitted, then there will be fewer threads to handle the new work?

Sometimes. ForkJoinPool may internally generate new ones -- always
enough to avoid starvation, but usually fewer than the parallelism level.
When some subtasks are expected to block or take
a much longer time than others, it is more efficient
to use CountedCompleters instead, that avoid cascaded blocking
at the expense of harder-to-use APIs.

Thanks to Aleksey for making the profiler available!
It is, among other things, a helpful tool for showing
the impact of these kinds of design decisions.


More information about the Concurrency-interest mailing list