Possible hash synchronization bug exposed by AWT?

Mon Jul 26 13:58:00 GMT 2004

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