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

Jason T. Greene jason.greene at redhat.com
Thu Apr 17 14:49:19 EDT 2008

Bob Lee wrote:
> On Thu, Apr 17, 2008 at 7:32 AM, Jason T. Greene 
> <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>     - Can't do standard equality with weak/soft 
> Standard equality doesn't make sense for weak/soft. Weak/soft references 
> are fundamentally identity based.

I disagree. I think object lifetime and equality are orthogonal. Just 
because a key can be collected earlier than a normal java reference, 
does not mean that a map containing it should allow semantical 
duplicates, or not resolve an object that is semantically equivalent to 
a key.

> You're "interning" use case is a red herring--ReferenceMap is not an 
> efficient way to implement that.

I am referring to an intern pool that does not grow without bounds 
(could be soft or weak), not the exact implementation of String.intern().

Don't forget the soft key cache. If there is no guarantee you are 
reusing the same instance (objects can come from serialization, user 
code, etc), then you are wasting memory and having a higher chance of a 
cache miss.

>     - Requires a separate application thread for stale entry cleanup
> We use one thread for the whole VM (or optionally more threads). The VM 
> could even reuse it's reference-enqueing thread like it does for other 
> internal things. You have a *concurrent* map now. Why make clients do 
> the work and make the durations of their operations less consistent?

It's not a huge deal to require one additional thread, however as more 
and more frameworks do this, it creates a problem in a shared 
environment. Then once you need a pool you now have yet another 
management aspect. So for this to be practical IMO it needs to be part 
of the JVM.

I think the reason reusing the enqueing thread has not been easily 
exposed is that it could be stalled by application code. Although this 
particular case is most likely not an issue for a concurrent table 

The goal of the lazy implementation is to self-scale, since cleanup is 
reusing mutating threads. It also has a nice secondary benefits of not 
requiring changes to the reference system, so the candidate is easily 
backported (the implementation I posted runs on JDK5). Yet another 
benefit is it will be *very* easy to retrofit it to use ephemerons.

I do see your point that it can effect expected duration of operations, 
so this is definitely something that requires further investigation. 
However, I think we should sideline this, and focus on the API, which 
should be the same no matter what cleanup approach we take.

>     - Needs a lot of extra method dispatch
> I agree that it should not delegate, but I doubt we need to copy CHM 
> 100%, especially if we're in the same package.

It's important that CHM and any kind of concurrent reference map not 
share implementation, so that they can evolve separately, which is very 
likely to happen with all of the wait-free work going on right now.

>     Doug and I have been talking with some of the folks at Google about
>     this. They have been after a standardized solution as well.
> I've talked to Doug, in that I've sent him a couple ReferenceMap 
> revisions for review over the past three years. His latest feedback was 
> that he wanted to wait for the new key/value reference type he's been 
> working on, so we've been holding off for that.

The last thread I saw, he was asking you and Kevin for feedback 
(specifically API feedback), and since you had not yet responded, and 
others where asking for this functionality, we decided to move the 
discussion here.

Jason T. Greene
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list