Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 21803 invoked from network); 30 Jul 2002 03:46:50 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Jul 2002 03:46:50 -0000 Received: (qmail 2813 invoked by uid 97); 30 Jul 2002 03:47:16 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2766 invoked by uid 97); 30 Jul 2002 03:47:16 -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 2754 invoked by uid 98); 30 Jul 2002 03:47:15 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-Id: <5.1.0.14.0.20020730095023.042a69b8@pop.scioworks.com> X-Sender: john@pop.scioworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 10:01:09 +0800 To: "Jakarta Commons Developers List" From: John Yu Subject: RE: [Collections][SUBMIT] ReferenceMap. Take FOUR. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Paul, (see below) At 01:02 am 30-07-2002, you wrote: > > Hi Paul, > > > > Shouldn't purge() only be called when mutators (write > > methods) are called, not accessors (read methods)? > > > > My understanding is java.util.WeakHashMap only process the > > ref queue (in the processQueue() method) when mutators are called. > >Actually, that was my initial understanding as well. The >"take three" version of ReferenceMap only purged during mutations. >But after reviewing the source for java.util.WeakHashMap, >I discovered that it in fact clears out its ReferenceQueue >on all operations, even accessors (even simple ones like >isEmpty()). I'm looking at the 1.4 source, I'm not sure if >previous versions of WeakHashMap behaved the same way. I was looking at JDK 1.3 source. WeakHashMap clears the ref queue only in mutators in 1.3. Perhaps it's worthwhile to do a diff to see why/what/how Sun changes WeakHashMap. > > If queueQueue() were called in accessors, iterators which are > > backed by the map would get into an invalid state when > > accessors were called. This breaks the Map interface contract. > > > > Or do I miss something? > >Although all of the Map implementations supplied by the JDK >provide fail-fast iterators, the fail-fast behavior isn't >specified by the Map contract. > >Also, although common Map implementations behave this way, >it isn't required that a read operation not alter the state >of the map. For instance, in java.util.LinkedHashMap, the >mere act of accessing a key can structurally modify the Map. >(Apache's LRUMap behaves similarly). > >Basically the issue is that there's no such thing as an >unmodifiable ReferenceMap. Like WeakHashMap, it behaves as >if an invisible thread is silently removing mappings. > >Note that ReferenceMap iterations in a single-thread context >are safe, because the iterators don't purge stale entries >(the iterators just skip over stale entries), and because >no other thread is accessing the map. In a multithreaded >context, the iterations should be synchronized properly, >which would lock out other operations, even read operations. Probably you are right. The 1.3 impl misleads me. I've re-examined 1.3's WeakHashMap source. It seems the processQueue() method can have been safely called in *all* methods. -- John Yu Scioworks Technologies e: john@scioworks.com w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 -- To unsubscribe, e-mail: For additional commands, e-mail: