[concurrency-interest] RFC -- Java7 java.util.concurrent plans

Doug Lea dl at cs.oswego.edu
Tue Dec 9 19:35:45 EST 2008

Concrete plans for Java7 release finally appear to be starting, and
we've been asked which JSR166 follow-ons should be slated for
inclusion. Here is the tentative list. Comments appreciated.

1. Phasers
    A generalization of various kinds of barriers.
2. LinkedTransferQueue (and TransferQueue interface)
    A generalization of nonblocking, blocking and synchronous queues
3. ConcurrentReferenceHashMap
    A concurrent hash map allowing weak, soft, etc keys and values.
4. Fences (in java.util.concurrent.atomic)
    Low-level memory fences
5. ForkJoin framework.
    (See below)

Preliminary versions of these can be found in various places.
Phasers and LinkedTransferQueues are in jsr166y at

The Fences API is listed at
The specs need a little bit of work, and Java JVMs will need to
support it. (Any VM can support it now extremely expensively, but it
is not useful unless supported efficiently.)  Among other reasons for
including this API is to better correspond to the similar upcoming
C++0x APIs.

Jason Greene created a version of ConcurrentReferenceHashMap based on
ConcurrentHashMap. I think the most recent version is at:
We postponed integrating this awaiting possible GC support for
Ephemerons (a solution to  weak key-value chains), which
might drive different internals.  But I don't think Ephemeron support
is too likely to be in place soon, so we should consider incorporating
without this.

As most people know, existing ForkJoin support consists of two parts,
the base ForkJoin{Pool,Task} framework, and the parallel collections
(currently only ParallelArray) on top if it.  I'm thinking to only
recommend inclusion of the base framework into JDK, and to resume
working on parallel collections as a non-JDK package.  Doing this
sidesteps the interface explosion issue (the 96 interfaces like
IntAndLongToInt etc etc) and expressiveness issues (closures etc) that
make inclusion in JDK hard to argue for, while better motivating
development and usage of parallelCollections package over the
medium-term future, and as well as possible development of
associated IDE support, language extensions and/or other JVM languages

At the same time, I've been working on revisions of the base support
that provide full integration of FJ with the Executor framework --
ForkJoinPool will implement Executor service and ForkJoinTask will
implement Future. (The main idea making this possible is to allow
controlled blocking and spawning spare threads when necessary to
maintain parallelism.) Among the motivations is to accommodate usages
in both Fortress and X10 (which are or will be compiled to run on
JVMs) requiring this sort of capability. But it also comes into play
in constructions that people have wanted but hadn't worked, like
creating a set of looping (non-FJ-like) tasks, each of which
sometimes spawns FJ tasks.

More details will follow (getting the internal parallelism maintenance
working well is going slowly), but this invites simply adding the base
framework to java.util.concurrent proper: class ForkJoinPool (with class
ForkJoinWorkerThread still available for advanced usages and tuning)
plus abstract class ForkJoinTask, with support
for the three basic flavors via abstract subclasses RecursiveAction,
RecursiveTask, AsyncForkJoinAction (the last one revamped to enable
construction of classes like BinaryAsyncAction without needing to
provide them.)

I'll await comments and suggestions on all this before putting
it into place. (Where putting in place means initially
reorganizing package jsr166y along these lines, and later
transferring to java.util.concurrent.)


More information about the Concurrency-interest mailing list