Hash synchronization

Bryce McKinlay mckinlay@redhat.com
Wed Aug 11 04:45:00 GMT 2004


I've tested the patch on a 4-way PPC system and a 4-way opteron system 
and can no longer reproduce the bug, so it looks good to me. I think 
leaving the logging code in is fine - it doesn't effect performance when 
its not enabled and may help others understand and debug the code in 
future. Please go ahead and check it in if you're happy with it. We 
should also consider this patch for the 3.4 branch.



Boehm, Hans wrote:

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

More information about the Java mailing list