Patch: FYI: fix PR libgcj/23353

[Tom Tromey]

I'm checking this in on the trunk and the 4.0 branch.

PR libgcj/23353 points out that Object.clone() improperly copies the
sync_info field from the old object to the new one, causing them to
share the same lock.  I think this bug has been around forever.  It
only affects systems that don't use hash synchronization.

Tom

Index: ChangeLog
from  Morgan Deters  <mdeters@morgandeters.com>

	PR libgcj/23353:
	* java/lang/natObject.cc (clone): Clear sync_info.

Index: java/lang/natObject.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/lang/natObject.cc,v
retrieving revision 1.34
diff -u -r1.34 natObject.cc
--- java/lang/natObject.cc 14 May 2005 00:42:46 -0000 1.34
+++ java/lang/natObject.cc 12 Aug 2005 16:38:26 -0000
@@ -1,6 +1,6 @@
 // natObject.cc - Implementation of the Object class.
 
-/* Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003  Free Software Foundation
+/* Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2005  Free Software Foundation
 
    This file is part of libgcj.
 
@@ -104,6 +104,11 @@
     }
 
   memcpy ((void *) r, (void *) this, size);
+#ifndef JV_HASH_SYNCHRONIZATION
+  // Guarantee that the locks associated to the two objects are
+  // distinct.
+  r->sync_info = NULL;
+#endif
   return r;
 }