Possible hash synchronization bug exposed by AWT?

[Jacob Gladish]

Oh... I forgot. This code is running on both dual p3 and dual p4
machines. The p4's have hyperthreading disabled.


-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
Of Jacob Gladish
Sent: Monday, July 26, 2004 9:58 AM
To: 'Bryce McKinlay'
Cc: hans.boehm@hp.com; java@gcc.gnu.org
Subject: RE: Possible hash synchronization bug exposed by AWT?


I have been unable to repro the IllegalMonitorStateException. The test
case I sent out that that revealed the deadlock in the hash sync was
what I used to do the timing experiment. I was slightly modified to
track timing. Now that I think about it, the runtime was built with a
hash sync table size of 1. This may have been the cause of the slowness.
The spinning was just a guess on my part. I couldn't come up with
anything else that made sense. I didn't have time to dig into it.


-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
Of Bryce McKinlay
Sent: Friday, July 23, 2004 9:48 PM
To: Jacob Gladish
Cc: hans.boehm@hp.com; java@gcc.gnu.org
Subject: Re: Possible hash synchronization bug exposed by AWT?


Jacob Gladish wrote:

>I've seen that exact same thing a couple times before. I really
>couldn't figure out what was going on. This is why I thought there may 
>be some type of race condition in the hash sync code, which is what 
>motivated me to write that test case which ended up revealing the 
>deadlock that Hans identified.
>  
>
Interesting. Are you seeing the bug on a multiprocessor/hyperthreading 
system? I don't suppose you have been able to come up with a test case 
to easily reproduce it? :)

>I have since rebuilt the environment with hash sync off. On another
>note, I actually witnessed something interesting. The initial theory 
>was that my test was going to be significantly slower with hash sync 
>off because of the heavy use of java.util.Vector (everything is 
>synchronized), but the test with hash sync off was actually much 
>faster.
>  
>
I don't think hash synchronization was ever claimed to be faster than 
standard synchronization. Rather, the advantage is that no 
synchronization field is required in every object. This saves 1 word per

object, which can be quite significant in the context of a large 
application. The idea is that any extra overhead from the hash 
synchronization is more than made up for in performance improvements due

to better cache locality, etc.

It is a bit worrying, however, if you are seeing significant performance

degradation from using hash synchronization. Do you have a test 
case/benchmark that demonstrates this?

I think Hans is on vacation right now, hopefully when he gets back he'll

be able to offer some insight.

>The only thing I have come up with for this is that threads where
>sleeping in monitor enter when attempting to acquire a lightweight lock

>which was already in the heavyweight state. This may be completely
>inaccurate since I never confirmed that if the lock was already in the 
>heavyweight state whether the thread entered the spin/sleep loop.
>
>It did seem like the runtime performed better with hash sync off when
>the application experiences lots of lock contention.
>  
>
The common assumption is that in real-world applications, uncontended 
locks are by far the common case, and thus its better to optimize for 
no-contention locks even if it means that things are slower in the 
contented case. I admit to being suspicious as to the merits of 
spinning, however.

Regards

Bryce