RFR: 8154739: AArch64: TemplateTable::fast_xaccess loads in wrong mode

[Andrew Haley]

I've seen weird unexplained (and unrepeatable) segfaults during JDK
builds for years.  They're vary rare, and I thought it was to do with
flaky prototype hardware -- or at least that's how I kidded myself.
Yesterday I found a culprit.  It's a load in one of the bytecode
accelerators, the one which replaces _aload_0, _fast_igetfield.

Instead of a 32-bit word load, it's a 64-bit xword load.  So how can
this lead to a crash?  Well, if the object in question is at the very
end of the heap and the integer field is at the very end of the
object, you'll get a read which spills over onto the next page in
memory.  This requires quite a coincidence of events, but it happens.

Also, I discovered that the volatile load case had only a LoadLoad: it
needs a LoadStore too.

Thanks,

Andrew.


# HG changeset patch
# User aph
# Date 1461150850 0
#      Wed Apr 20 11:14:10 2016 +0000
# Node ID 0df9b5892b864f27524480a698fe2550b4f9e531
# Parent  57f9554a28f1858c009b4c4f0fdcb42079f4c447
8154739: AArch64: TemplateTable::fast_xaccess loads in wrong mode
Reviewed-by: roland

diff --git a/src/cpu/aarch64/vm/templateTable_aarch64.cpp b/src/cpu/aarch64/vm/templateTable_aarch64.cpp
--- a/src/cpu/aarch64/vm/templateTable_aarch64.cpp
+++ b/src/cpu/aarch64/vm/templateTable_aarch64.cpp
@@ -2982,7 +2982,7 @@
   __ null_check(r0);
   switch (state) {
   case itos:
-    __ ldr(r0, Address(r0, r1, Address::lsl(0)));
+    __ ldrw(r0, Address(r0, r1, Address::lsl(0)));
     break;
   case atos:
     __ load_heap_oop(r0, Address(r0, r1, Address::lsl(0)));
@@ -3000,7 +3000,7 @@
     __ ldrw(r3, Address(r2, in_bytes(ConstantPoolCache::base_offset() +
                                      ConstantPoolCacheEntry::flags_offset())));
     __ tbz(r3, ConstantPoolCacheEntry::is_volatile_shift, notVolatile);
-    __ membar(MacroAssembler::LoadLoad);
+    __ membar(MacroAssembler::LoadLoad | MacroAssembler::LoadStore);
     __ bind(notVolatile);
   }