BZ #151: openjdk6 cacao on MIPS crash due to assertion in lock_inflate

Status fields:

creation_ts:2010-11-21 13:20
component:jit
version:unspecified
rep_platform:mips64
op_sys:Linux
bug_status:RESOLVED
resolution:WONTFIX
reporter:drazzib@drazzib.com
Hi,

Here is the bug report I get from user of Debian GNU/Linux :
[full details on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539924]

When using cacao (icedtea-6-jre-cacao 6b16-4) to run ant I am getting the following
intermittent assertion failure:

java: lock.c:801: lock_inflate: Assertion `((lockword) & ~(((1 << 8) - 1) << 1)) ==
t->thinlock' failed.

Note that this is intermittent -- it fails only about half the time.

The hardware is a Cavium Octeon with 12 MIPS64R2 CPUs.


Proposed solution :

I added the memory barrier instructions and the JRE appears to be working.

Here is the patch:

--- cacao-0.99.4/src/vm/jit/mips/md-atomic.hpp~ 2009-08-27 15:30:44.000000000 -0400
+++ cacao-0.99.4/src/vm/jit/mips/md-atomic.hpp  2009-08-27 13:13:07.000000000 -0400
@@ -127,12 +127,12 @@
  */
 inline static void Atomic_memory_barrier(void)
 {
-       __asm__ __volatile__ ("" : : : "memory");
+       __asm__ __volatile__ (".set mips64; sync; .set mips0" : : : "memory");
 }


-#define STORE_ORDER_BARRIER() __asm__ __volatile__ ("" : : : "memory");
-#define MEMORY_BARRIER_AFTER_ATOMIC() __asm__ __volatile__ ("" : : : "memory");
+#define STORE_ORDER_BARRIER() __asm__ __volatile__ (".set mips64; sync; .set mips0" : :
: "memory");
+#define MEMORY_BARRIER_AFTER_ATOMIC() __asm__ __volatile__ (".set mips64; sync; .set
mips0" : : : "memory");

 #endif // _MD_ATOMIC_HPP


I suspect that the above may not be optimal -- I think that the hardware I have
(OCTEON CN5650-NSP pass 2.1, 12 CPUs at 600 MHz) does not require read barriers.
Someone with more expertise is needed to tune this.

Comment #1 by stefan@complang.tuwien.ac.at on 2010-12-29 20:06:49

Thanks for the report. Unfortunately, we don’t have access to any MIPS64 hardware and
haven’t had in years, actually. I’m glad to see that the user was apparently able to fix
that himself.

Comment #2 by stefan@complang.tuwien.ac.at on 2011-01-20 22:15:01

Sorry...