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

Ben Manes ben_manes at yahoo.com
Tue Dec 30 05:35:58 EST 2008


In regards to the ConcurrentReferenceHashMap, there does not seem to be a way to be notified when an entry has been evicted.  Google's ReferenceMap has a similar issue, since neither expose listeners or their reference queues, but does allow a partial work-around.  In my usage, I supply a backing map whose "remove" methods invokes an eviction listener after performing the operation.  This allows me to update the cache's statistics, as well as perform various cleanup logic (e.g. a decorator allows mapping N keys -> value, so when evicted a call-back cleans up the index keys).  This works out fairly well, with the flaw being that removal coming down the decorator call-stack would spuriously increment the statistic's eviction count.  Since my users are forced to allow the framework to handle consistency issues, they are not able to explicitly request a removal and its a non-issue.  However, many other caching frameworks do allow direct removal as well as
 attaching custom listeners for eviction, which would make it difficult to adapt either implementation.  For the decorated approach, one would probably need to use a fairly hacking method like inspecting a ThreadLocal flag to determine which route the method was invoked from.  For the proposed Java-7 version, I can't think of any approach at the moment.




________________________________
From: Doug Lea <dl at cs.oswego.edu>
To: Concurrency-interest at cs.oswego.edu
Sent: Tuesday, December 9, 2008 4:35:45 PM
Subject: [concurrency-interest] RFC -- Java7 java.util.concurrent plans

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
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html

The Fences API is listed at
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html
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:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/experimental/jsr166/src/jsr166y/ConcurrentReferenceHashMap.java?view=markup
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.)

-Doug


_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20081230/4c76dce0/attachment.html>


More information about the Concurrency-interest mailing list