Possible hash synchronization bug exposed by AWT?

Sat Jul 24 01:48:00 GMT 2004

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