This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Possible hash synchronization bug exposed by AWT?


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. 

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.
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. 



-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
Of Bryce McKinlay
Sent: Wednesday, July 21, 2004 7:35 PM
To: java@gcc.gnu.org
Cc: Boehm, Hans
Subject: Possible hash synchronization bug exposed by AWT?


We've noticed an intermittent synchronization problem that occurs 
(occasionally) when starting AWT applications on i686-pc-linux-gnu, 
possibly only on multiprocessor/hyperthreading systems.

What happens is that an IllegalMonitorStateException ("current thread 
not owner") is thrown from _Jv_MonitorExit when leaving 
EventQueue.getNextEvent() - a seemingly impossible situation. When this 
occurs there is another thread blocked in EventQueue.postEvent() waiting

for the lock.

I've posted a bug report with more details here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662

Any ideas? Has anyone else seen this?

Regards

Bryce



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]