commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <...@apache.org>
Subject RE: [Commons-Avalon:collections] code integration
Date Thu, 20 Jun 2002 15:54:48 GMT
On Thu, 20 Jun 2002, Berin Loritsch wrote:
> > From: Michael A. Smith [mailto:mas@apache.org] 
> 
> > I do have a couple of concerns with the BucketMap.  In a 
> > quick glance, it looks like it doesn't follow the Map 
> > contract -- the colletion views are not backed by the map.  
> > The new commons collections test suite for Map 
> > implementations should check for that, along with potentially other 
> > differences from the Map contract.  Any differences in contract would 
> > have to be resolved. 
> 
> BTW, I wrote the BucketMap.  My primary concern while
> writing it was fine-grained locking.  At that it excells.  The
> process of adding, removing, and looking up information far
> exceeds a Synchronized Map or Hashtable when multiple threads
> are trying to do the same thing.
> 
> The main focus was an add/remove/lookup--not the rest of the
> Map contracts.  That is because of the focus of what it is
> used for.

yup, I understand that...  My point is that the rest of the map contract 
should be addressed as well.  :)

btw, one thing that java.util.HashMap and java.util.Hashtable provide is 
the ability to have the underlying hashtable grow when the contents of 
the hashtable grow to a certain load factor of the size of the 
underlying table.  I didn't see the same feature in BucketMap.  Wouldn't 
that mean that BucketMap would degrade in performance significantly 
(compared with java.util's hash based maps) as the size of the map 
increases well beyond its number of buckets?  

btw, I'd be happy to fix that issue in BucketMap once it's moved over.  
It's really not that difficult to do and wouldn't have an impact on 
thread contention, although it probably would increase the memory 
footprint a bit and add a couple of operations for each lookup (a 
bitwise &, an array dereference, a comparison to see if the 
expansion threshold had been reached, and the amortized cost of table 
expansion).  

regards
michael



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message