Against hidden read barriers in intrinsics

[Andrew Haley]

We have some hand-coded AArch64 intrinsics, and they're being
converted to the modular GC interface.  However, I've noticed a
dangerous coding practice that we should stop before it starts.
In mainline jdk's MacroAssembler::arrays_equals, we have

    cmpoop(a1, a2);
    br(EQ, SAME);
    ...

As of today, MacroAssembler::cmpoop() does a Brooks pointer
dereference on *both* operands, and the following code relies on that
for correctness.  So, it's correct even for Shenandoah, but is a
ticking bomb.  If any programmer comes along and moves some code
before that innocuous-looking cmpoop(), it'd be looking at stale
copies of the data.

When Shendandoah is merged into mainline we must not do this.  Let us
instead EXPLICITLY do

  resolve_for_read(IN_HEAP, a1);
  resolve_for_read(IN_HEAP, a2);

  ...
  cmp(a1, a2);

This has the additional advantage that the read barrier is done as
early as possible.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671