[concurrency-interest] ConcurrentReferenceMap enhancement to 166 - Feedback Requested

Jason T. Greene jason.greene at redhat.com
Thu Apr 17 10:32:54 EDT 2008

Dhanji R. Prasanna wrote:
> Hi Jason (Greene)
> This is cool =)
> I also prefer the enum as it is a tight contract. 
> Btw, doesn't google-collections have a similar utility? > I notice that it 
> uses a composition pattern with CHM, and that your version does not. 

Yes, for others that are interested. Google has a similar table here 
(under ASL):

It uses a delegation approach which is more limiting:
- Can't do standard equality with weak/soft types
- Requires a separate application thread for stale entry cleanup
- Needs a lot of extra method dispatch

Doug and I have been talking with some of the folks at Google about 
this. They have been after a standardized solution as well.

 > Can I ask about the motivation for this? (I presume, without due 
 > that a similar lock-striping strategy to CHM is in use?)

The motivation is to maximize performance, and solve the above issues. 
It's actually a derivative of the CHM code, so pretty much the same 
performance aspects, with of course some small additional overhead for 
tracking references. So, reads are non-blocking, writes are striped. 
Each segment has it's own reference queue that is lazily purged when a 
lock is acquired on that segment. There is also a purgeStaleEntries() 
method that can be called from any thread should an application wish to 
do this eagerly, although this triggers a lock acquisition on all 
segments, one at a time.

Jason T. Greene
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list