Synchronization article on developerWorks

Tue Jul 24 16:09:00 GMT 2001

I just tried Tom's program on my Pentium II/300 running RH6.2. I see a
bigger difference between 3.0 and 3.1. I have some local changes in my
tree, but I don't think they effect the empty or staticEmpty test.
There are several reasons synchronization might be cheaper in 3.1:
1) The common path is a bit shorter. 
2) There is 1 word less space overhead per object.
3) A simple uncontested synchronization doesn't allocate a structure.
4) Contended synchronization might be handled better. If so linuxthreads
should really do the same.
I suspect linuxthreads has gotten better recently. This may have reduced
the effect of (1) and (4) as you go to more recent Linux distributions.
That's good. We should all thank Ulrich Drepper.
Advantages (2) and (3) are not exercised here, though they are by things
like frequent use of StringBuffer.
Wild conjecture: The developerWorks results are from a gcj build that has
threads disabled? Isn't that still the default?
Hans
> -----Original Message-----
> From: Jeff Sturm [ mailto:jsturm@one-point.com ]
> Sent: Tuesday, July 24, 2001 3:47 PM
> To: Tom Tromey
> Cc: Bryce McKinlay; java@gcc.gnu.org
> Subject: Re: Synchronization article on developerWorks
>>>>> On 24 Jul 2001, Tom Tromey wrote:
> > 3.1 is generally better than 3.0 (not sure why). However, 
> I expected
> > more dramatic results from 3.1-with-sync.
>> Using your bench.java, I see similar results on alpha, e.g. a 
> factor of
> 22/18 for 3.0.1/3.1 in the empty call.
>> I don't understand how this author got the results he did. It doesn't
> look like he made his source available.
>> These locks have no contention though. On a test program with high
> contention I observed a 2-3x speedup with hash synchronization.
>> Jeff
>