Re: Possible hash synchronization bug exposed by AWT?

[Bryce McKinlay <mckinlay at redhat dot com>]

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