[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
> 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
> - 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
Jason T. Greene
JBoss, a division of Red Hat
More information about the Concurrency-interest