<div>I think adding eviction callbacks is beyond the scope of ReferenceMap, but caching frameworks can use the underlying &quot;finalizable reference&quot; API directly to get what you want.</div><div><br></div><div>This is what I&#39;m doing in our own caching classes anyway (rather than try to wrap ReferenceMap).</div>
<div><br></div><div>Bob<br><br><div class="gmail_quote">On Tue, Dec 30, 2008 at 2:35 AM, Ben Manes <span dir="ltr">&lt;<a href="mailto:ben_manes@yahoo.com">ben_manes@yahoo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div style="font-family:times new roman,new york,times,serif;font-size:10pt"><div>In regards to the ConcurrentReferenceHashMap, there does not seem to be a way to be notified when an entry has been evicted.&nbsp; Google&#39;s ReferenceMap has a similar issue, since neither expose listeners or their reference queues, but does allow a partial work-around.&nbsp; In my usage, I supply a backing map whose &quot;remove&quot; methods invokes an eviction listener after performing the operation.&nbsp; This allows me to update the cache&#39;s statistics, as well as perform various cleanup logic (e.g. a decorator allows mapping N keys -&gt; value, so when evicted a call-back cleans up the index keys).&nbsp; This works out fairly well, with the flaw being that removal coming down the decorator call-stack would spuriously increment the statistic&#39;s eviction count.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; For the proposed Java-7 version, I can&#39;t think of any approach at the moment.<br>
</div><div style="font-family:times new roman,new york,times,serif;font-size:10pt"><br><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><font face="Tahoma" size="2"><div class="Ih2E3d"><hr size="1"><b><span style="font-weight:bold">From:</span></b> Doug Lea &lt;<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a>&gt;<br>
<b><span style="font-weight:bold">To:</span></b> <a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br><b><span style="font-weight:bold">Sent:</span></b> Tuesday, December 9, 2008 4:35:45 PM<br>
</div><b><span style="font-weight:bold">Subject:</span></b> [concurrency-interest] RFC -- Java7 java.util.concurrent plans<br></font><div><div></div><div class="Wj3C7c"><br>
Concrete plans for Java7 release finally appear to be starting, and<br>we&#39;ve been asked which JSR166 follow-ons should be slated for<br>inclusion. Here is the tentative list. Comments appreciated.<br><br>1. Phasers<br>
&nbsp;  A generalization of various kinds of barriers.<br>2. LinkedTransferQueue (and TransferQueue interface)<br>&nbsp;  A generalization of nonblocking, blocking and synchronous queues<br>3. ConcurrentReferenceHashMap<br>&nbsp;  A concurrent hash map allowing weak, soft, etc keys and values.<br>
4. Fences (in java.util.concurrent.atomic)<br>&nbsp;  Low-level memory fences<br>5. ForkJoin framework.<br>&nbsp;  (See below)<br><br>Preliminary versions of these can be found in various places.<br>Phasers and LinkedTransferQueues are in jsr166y at<br>
<a href="http://gee.cs.oswego.edu/dl/concurrency-interest/index.html" target="_blank">http://gee.cs.oswego.edu/dl/concurrency-interest/index.html</a><br><br>The Fences API is listed at<br><a href="http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html" target="_blank">http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html</a><br>
The specs need a little bit of work, and Java JVMs will need to<br>support it. (Any VM can support it now extremely expensively, but it<br>is not useful unless supported efficiently.)&nbsp; Among other reasons for<br>including this API is to better correspond to the similar upcoming<br>
C++0x APIs.<br><br>Jason Greene created a version of ConcurrentReferenceHashMap based on<br>ConcurrentHashMap. I think the most recent version is at:<br><a href="http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/experimental/jsr166/src/jsr166y/ConcurrentReferenceHashMap.java?view=markup" target="_blank">http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/experimental/jsr166/src/jsr166y/ConcurrentReferenceHashMap.java?view=markup</a><br>
We postponed integrating this
 awaiting possible GC support for<br>Ephemerons (a solution to&nbsp; weak key-value chains), which<br>might drive different internals.&nbsp; But I don&#39;t think Ephemeron support<br>is too likely to be in place soon, so we should consider incorporating<br>
without this.<br><br>As most people know, existing ForkJoin support consists of two parts,<br>the base ForkJoin{Pool,Task} framework, and the parallel collections<br>(currently only ParallelArray) on top if it.&nbsp; I&#39;m thinking to only<br>
recommend inclusion of the base framework into JDK, and to resume<br>working on parallel collections as a non-JDK package.&nbsp; Doing this<br>sidesteps the interface explosion issue (the 96 interfaces like<br>IntAndLongToInt etc etc) and expressiveness issues (closures etc) that<br>
make inclusion in JDK hard to argue for, while better motivating<br>development and usage of parallelCollections package over the<br>medium-term future, and as well as possible development
 of<br>associated IDE support, language extensions and/or other JVM languages<br><br>At the same time, I&#39;ve been working on revisions of the base support<br>that provide full integration of FJ with the Executor framework --<br>
ForkJoinPool will implement Executor service and ForkJoinTask will<br>implement Future. (The main idea making this possible is to allow<br>controlled blocking and spawning spare threads when necessary to<br>maintain parallelism.) Among the motivations is to accommodate usages<br>
in both Fortress and X10 (which are or will be compiled to run on<br>JVMs) requiring this sort of capability. But it also comes into play<br>in constructions that people have wanted but hadn&#39;t worked, like<br>creating a set of looping (non-FJ-like) tasks, each of which<br>
sometimes spawns FJ tasks.<br><br>More details will follow (getting the internal parallelism maintenance<br>working well is going slowly), but this invites simply adding the
 base<br>framework to java.util.concurrent proper: class ForkJoinPool (with class<br>ForkJoinWorkerThread still available for advanced usages and tuning)<br>plus abstract class ForkJoinTask, with support<br>for the three basic flavors via abstract subclasses RecursiveAction,<br>
RecursiveTask, AsyncForkJoinAction (the last one revamped to enable<br>construction of classes like BinaryAsyncAction without needing to<br>provide them.)<br><br>I&#39;ll await comments and suggestions on all this before putting<br>
it into place. (Where putting in place means initially<br>reorganizing package jsr166y along these lines, and later<br>transferring to java.util.concurrent.)<br><br>-Doug<br><br><br>_______________________________________________<br>
Concurrency-interest mailing list<br><a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br><a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</div></div></div></div></div><br>

      </div><br>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br></blockquote></div><br></div>