[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.util.Hashtable.size()/isEmpty()

From: Artur Biesiadowski
Subject: Re: java.util.Hashtable.size()/isEmpty()
Date: Fri, 15 Feb 2002 18:03:03 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020202

Etienne M. Gagnon wrote:
Artur Biesiadowski wrote:

First - removing as much synchronization as possible, while staying compatible is certainly a good thing. Synchronizing is _really_ costly -

Have you heard of "thin locks" and other VM level optimizations that reduces "significantly" the cost of locks? Do not compute the cost of locks based on their implementation in Sun's old JDK, or based on an implementation that does not implement state-of-the-art techniques.

By your definition, 1.3 hotspot is not a state-of-art implementation... Ok, I have tried also with ibm, and cost was smaller - something like 2.5 times slower.

Do you know any state-of-art jvms ? Hotspot, ibm and orp have quite costly locks :)

As for the Hashtable size(). Is there any point where it matters ?

Yes. The "synchronize" will force the "current processor" to update its data cache. Without the synchronize keyword, you processor could read an obsolete value from its local cache, even though all other methods are synchronized. e.g:

I DO understand why synchronization is needed in general case. I was asking about scenario in which _Hashtable.size()_ synchronization would make a difference. Except using it as different way of synchronized(anything) {} - but this is not in spec (I mean that Hashtable.size() javadoc does not require us to create a memory barrier as a side effect).

In other mail I've explained why it doesn't matter with clear() (and why it would matter if clear would decrease size one by one). I'm looking exactly for such example - some test which can possibly show that size() is unsynchronized. Remember that you cannot really use words 'later' and 'before' comparing threads, because before synchronization happens, temporal relation between them is 'fuzzy'.


Sorry for defending my ideas so strong, but this is quite important point - it can affect implementation of many other classes and it would be good to create some kind of consensus.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]