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

Bob Lee crazybob at crazybob.org
Tue Dec 30 09:27:16 EST 2008


I think adding eviction callbacks is beyond the scope of ReferenceMap, but
caching frameworks can use the underlying "finalizable reference" API
directly to get what you want.

This is what I'm doing in our own caching classes anyway (rather than try to
wrap ReferenceMap).

Bob

On Tue, Dec 30, 2008 at 2:35 AM, Ben Manes <ben_manes at yahoo.com> wrote:

> 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
>
>
> _______________________________________________
> 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/1d759395/attachment-0001.html>


More information about the Concurrency-interest mailing list