Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 59565 invoked from network); 20 Jun 2002 15:54:53 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Jun 2002 15:54:53 -0000 Received: (qmail 11365 invoked by uid 97); 20 Jun 2002 15:54:57 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 11349 invoked by uid 97); 20 Jun 2002 15:54:56 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 11337 invoked by uid 98); 20 Jun 2002 15:54:56 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: champion.sslsecure.com: iammichael owned process doing -bs Date: Thu, 20 Jun 2002 10:54:48 -0500 (CDT) From: "Michael A. Smith" X-X-Sender: iammichael@champion.sslsecure.com To: Jakarta Commons Developers List , Subject: RE: [Commons-Avalon:collections] code integration In-Reply-To: <003701c2186f$81a55dd0$ac00a8c0@Gabriel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: