This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Possible hash synchronization bug exposed by AWT?
- From: "Jacob Gladish" <jake at gladish dot info>
- To: "'Bryce McKinlay'" <mckinlay at redhat dot com>,<hans dot boehm at hp dot com>
- Cc: <java at gcc dot gnu dot org>
- Date: Thu, 22 Jul 2004 11:18:21 -0400
- Subject: 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