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

Tim Halloran hallorant at gmail.com
Thu Apr 17 09:21:35 EDT 2008


Working with this code, I propose a few (attached) changes for folks to try
out, I sent this to Jason earlier, but here it is for everyone to
examine/critique.

1) Three accessors have been added to allow client code to interrogate the
collection about its options: usingReferenceEquality(),
getKeyReferenceType(), and getValueReferenceType();  Since this is a general
purpose collection these should be able to be interrogated.

2) The Option enum is now just a boolean.  It sounds like the addition of
ephemeron-like weak refs would add another type to ReferenceType Enum.  Also
if a lot of options are added later, the this option enum could be added.
EnumSet won't clash with a current constructor, and the internal
representation of the use reference equality is just a boolean in the
current implementation.  Also the special constructor are probably still
desired, even after that change is made.

3) I added two new constructors:

  public ConcurrentReferenceHashMap(boolean useReferenceEquality)
  public ConcurrentReferenceHashMap(ReferenceType keyReferenceType,
            ReferenceType valueReferenceType, boolean useReferenceEquality)

which are helpful if reference-equality is being used.

4) I tried to make the discussion of reference-equality and object-equality
consistent with Josh Bloch's comments on IdentityHashMap.  I also changed
some field parameter names in this area as part of this effort.  I had
trouble following the variable naming in this area.

5) I did a pass through the Javadoc on the class and on the new
methods/constructors to be clearer.

The test cases I was using are also attached.

Issues I'd like to highlight are:

o The reference-equality option only affects keys at the moment.  (Jason
brought this up in an earlier email; I have not looked into this too much
yet)

o No test cases test the reference-equality option.

o The implementation passes its options into the segments.  Since there are
two references and a boolean, a reference to the outer class might be
cheaper, requiring only one reference.  I did NOT change this, just a note
for consideration.

o The local variables "sum" and "c" (two times) at lines 1248, 1251, and
1259 are never read.  I didn't remove them as this same three unused local
variables exist in ConcurrentHashMap (at lines 807, 810, and 819).  I think
these declarations can be safely removed, but I've been wrong before :-)

Best Regards,
Tim


On Wed, Apr 16, 2008 at 1:46 PM, Jason T. Greene <jason.greene at redhat.com>
wrote:

> We are currently considering the inclusion of a ConcurrentReferenceMap
> into a JSR-166 update. This map supports any combination of weak, soft,
> or strong keys and values with similar performance characteristics to
> ConcurrentHashMap (non-blocking reads, striped writes etc). This map can
> also be configured to use identity checking instead of standard equality
> when locating keys (similar to IdentityHashMap).
>
> At this point, we are looking for feedback, in particular on the API.
>
> Some of the open questions are:
>
> 1) Should the IDENTITY_COMPARISONS option apply to values and keys, or
> just to keys as it does now? If not, should there be separate options
> for both?
>
> 2) Should the key reference type, and the value reference type be merged
> into the option enum, instead of providing separate parameters? This
> reduces the number of overloaded constructors, but introduces the
> problem of having a combination of mutually exclusive options (WEAK_KEYS
> + SOFT_KEYS).
>
> 3) Should the configuration values be exposed via get methods so that
> calling code can introspect the map configuration? Currently none of the
> standard collections allow you to do this (load factor, etc).
>
> 4) Should behavioral options be exposed as booleans instead? With only
> one option this makes since; however, depending on the answer to
> question number 1, which would add another option, and some expected GC
> changes to the JVM that would add yet another one, this would introduce
> way too many overloaded constructors.
>
> The javadoc for the initial version is available here:
> http://www.stacksmash.com/jsr166y
>
> The source code (public domain) is available here:
>
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/experimental/jsr166/src/jsr166y/ConcurrentReferenceHashMap.java?view=markup
>
> It should be noted that the API and implementation are extremely subject
> to change, and are also of pre-release quality, so it is not recommended
> for production usage. Also, these links are just temporary.
>
> Thanks!
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080417/32233f6d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConcurrentReferenceHashMap.java
Type: application/octet-stream
Size: 60418 bytes
Desc: not available
Url : /pipermail/attachments/20080417/32233f6d/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConcurrentReferenceHashMapGCTestCase.java
Type: application/octet-stream
Size: 5003 bytes
Desc: not available
Url : /pipermail/attachments/20080417/32233f6d/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConcurrentReferenceHashMapTest.java
Type: application/octet-stream
Size: 17955 bytes
Desc: not available
Url : /pipermail/attachments/20080417/32233f6d/attachment-0005.obj 


More information about the Concurrency-interest mailing list