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