[concurrency-interest] ConcurrentReferenceMap enhancement to 166 - Feedback Requested
markus.kohler at gmail.com
Fri Apr 18 02:59:45 EDT 2008
On Thu, Apr 17, 2008 at 10:21 PM, Bob Lee <crazybob at crazybob.org> wrote:
> On Thu, Apr 17, 2008 at 11:49 AM, Jason T. Greene <jason.greene at redhat.com>
> > 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 might be right, but after three years of heavy use, we have yet to
> encounter a use case which supports your assertion that we want equality
> instead of identity comparisons for weak and soft references. Not that it's
> not trivial to support both strategies, but I do like to steer users in the
> right direction. I've found that users have always needed identity
> comparisons, and I've also seen cases where using equality with weak
> references would have introduced subtle bugs (Class objects for example).
> > 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().
> I knew what you meant. We implement that sort of thing more efficiently
> and cleanly with a different data structure, so we shouldn't bend
> ReferenceMap too hard toward that use case.
That sounds very interesting. Can you give us more detail about the data
structure used, or is that confidential ?
We (SAP) have a special String.intern implementation in our JVM to
implement a pool of Strings efficiently. We considered just using a
WeakConcurrentHashmap implementation,but found the memory overhead per
String would be rather large.
I just got an idea some days ago, how we could reduce the number of Weak
references by loosening the contract of String.intern() .We don't need
actually the exact contract of String.intern for our String pooling
> > 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.
> Like I said, we only need one thread here for the whole VM and we can even
> reuse an existing thread and avoid the overhead of a reference queue.
> > 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).
> We've been running ReferenceMap on Java 5 for years.
> 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.
> I was forwarded an email where you sent out what amounted to a concurrent
> version of WeakHashMap, and we provided feedback--we pointed you to
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest