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]

Hash synchronization


Replying to several earlier messages:

- Hash synchronization should usually be a performance improvement, though
not with a table of size 1.  It usually avoids the lock allocation overhead,
which is often important.  It reduces the work done by the GC, by
making many objects pointer-free.  And the actual lock acquisition
path shouldn't be much different.  Looking back at some of my old
notes, for StringBuffer-intensive toy programs, I sometimes got close
to a factor of two.  It should do even better if we taught
the compiler a bit more about what's going on.

- The problem below is indeed a hash synchronization bug.
In staring at the code for a long time
trying to understand it again, I found a few other issues.  Attached
is a preliminary patch.  Testing is appreciated.  (I'm inclined to leave
the logging code in, though ifdef'ed out, to make this easier for any
future problems.  Does that make sense?)  Assuming someone can verify that
this indeed works, and my tests don't show any problems, is this OK to
check in?

2004-08-10  Hans Boehm <Hans.Boehm@hp.com>
	* java/lang/natObject.cc (LOCK_LOG, LOG):
	Add low overhead debug tracing.
	(Almost everywhere): add LOG calls, fix, add comments.
	(_Jv_MonitorEnter): Replace masking of LOCKED bit with assertion.
	Add explicit check for LOCKED bit in slow case (Bug 16662).
	(_Jv_MonitorExit): Add casts in debug-only code.
	Always release LOCKED bit before throwing exception.
	(_Jv_ObjectCheckMonitor): Lock may be held if lightweight lock
	isn't.  Handle easy cases without lock acquisition.
	(Object::wait): Use NotifyAll for lock inflation.

> -----Original Message-----
> From: Bryce McKinlay [mailto:mckinlay@redhat.com]
> Sent: Wednesday, July 21, 2004 4: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
> 

Attachment: natObject.diff
Description: Binary data


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