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

Kevin Bourrillion kevinb at google.com
Tue Dec 9 21:52:55 EST 2008


On Tue, Dec 9, 2008 at 6:31 PM, Bob Lee <crazybob at crazybob.org> wrote:

I'm curious as to what design aspects make ConcurrentReferenceHashMap
>> superior to Google's ReferenceMap.  It looks to have implemented its own
>> hash table, versus delegating to a backing ConcurrentMap, but I don't
>> immediately understand why this is preferable.
>>
>
> ReferenceMap must create an object every time you call get() and it must
> repeatedly lock/unlock in some situations whereas ConcurrentReferenceHashMap
> can just grab the lock once and get the job done. I haven't looked at the
> semantics of CRHM in awhile, but we have plenty of time to hammer those out.
>

A ReferenceMap that lives outside java.util, without access to java.util
internals, is forced to make this choice (either reimplement its own entire
data structure, or discard a dummy instance on every query like ours does).
We chose one way and Jason chose the other, but I'd still like to think that
neither horrible fate must be suffered for the JDK code.

For the record, Google's ReferenceMap is phenomenally well-tested and has
been in production in Google apps for more than three years.  The
performance impact of these discarded dummy instances has not been a serious
problem in practice (I still think it's unsuitable for JDK code, but also
unnecessary as explained above).  It's currently being used in 167 distinct
projects.  Through this we've worked out a lot of fiendish bugs.  The JDK is
welcome to as much or as little of its distilled wisdom as you please!


-- 
Kevin Bourrillion @ Google
internal:  go/javalibraries
google-collections.googlecode.com
google-guice.googlecode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20081209/bd7c4710/attachment.html>


More information about the Concurrency-interest mailing list