RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire

[Hui Shi]

Hi,

Could someone help review and sponsor this fix for aarch64 runtime?

Bug:  https://bugs.openjdk.java.net/browse/JDK-8143285
webrev:  http://cr.openjdk.java.net/~hshi/8143285/webrev/

In InterpreterMacroAssembler::get_cache_and_index_and_bytecode_at_bcp,
rewrite bytecode in ConstantPoolCacheEntry._indices is read with ldrw on
aarch64. Following loads (for example ConstantPoolCacheEntry._flags and
field offset) might finish before ConstantPoolCacheEntry._indices load and
get unexpected values. ConstantPoolCacheEntry._indices is read and write
with load acquire and store release in all other places. It also need load
acquire here to guarantee read correct field offset and flags from
ConstantPoolCacheEntry.

getfield emplate interpreter code before fix
  0x0000007f780a2aa4: ldrh      w3, [x22,#1]
  0x0000007f780a2aa8: add       x2, x26, x3, lsl #5
  0x0000007f780a2aac: ldr       w19, [x2,#16]
  0x0000007f780a2ab0: ubfx      x19, x19, #16, #8
  0x0000007f780a2ab4: cmp       x19, #0xb4
  0x0000007f780a2ab8: b.eq      0x0000007f780a2ba4

  0x0000007f780a2ba4: ldr       x19, [x2,#32]         // read field offset,
not ordered with rewrite byte code load
  0x0000007f780a2ba8: ldr       w0, [x2,#40]          // read flags, not
ordered with rewrite byte code load
  0x0000007f780a2bac: ldr       x4, [x20],#8

getfield template interpreter code after fix
  0x0000007f900a2ba8: add       x2, x26, x3, lsl #5
  0x0000007f900a2bac: add       x19, x2, #0x10
  0x0000007f900a2bb0: ldar      w19, [x19]
  0x0000007f900a2bb4: ubfx      x19, x19, #16, #8
  0x0000007f900a2bb8: cmp       x19, #0xb4
  0x0000007f900a2bbc: b.eq      0x0000007f900a2ca8

  0x0000007f780a2ba4: ldr       x19, [x2,#32]         // read offset,
ordered with rewrite byte code load
  0x0000007f780a2ba8: ldr       w0, [x2,#40]          // read flags，ordered
with rewrite byte code load
  0x0000007f780a2bac: ldr       x4, [x20],#8


This problem causes template interpreter code for getfield gets wrong
 ConstantPoolCacheEntry._flags with uninitialized tos state. As
uninitialized tos is "0" same with "btos", this is a little bit confusing
when debug (at first uninitialized tos is 0 and it doesn’t trigger error in
first execution of getfield, it triggers error in other thread when try to
patch byte code with different value), is it possible to use some magic
number here indicate the uninitialized "tos state" in _flags? For example
0xf, and it can trigger "bad state" error at first wrong palce.

Regards
Shi Hui