RFR: fix shenandoah store checks and implicit null checks on aarch64

[Roland Westrelin]

http://cr.openjdk.java.net/~roland/shenandoah/aarch64-storecheck-nullcheck/webrev.00/

1) When code is emitted in a scratch buffer to compute the size of a
store (for instance), with ShenandoahStoreCheck, the verification code
is emitted and allocates a string for the error message. When the code
is generated for good another string is allocated. Depending on its
address, the assembly code that loads the string in a register doesn't
always have the same shape. C2 can be confused if it sees a mismatch
between the size of the code in the scratch buffer and the final
code. The patch fixes this by choosing an arbitrary address that can
only be emitted with the worst case number of instructions when emitting
in the scratch buffer.

2) A shenandoah read barrier can trigger an implicit null check. In that
case the offset is -8 and the oop can be null. On a system where this
doesn't work properly, I see that the offset that
MacroAssembler::needs_explicit_null_check() sees is:

0xfffffffffffff8

that is 56 bits so not quite -8. With Universe::narrow_oop_base() not
null, offset + 8 is not 0 but a number bit enough to be greater than the
base and the offset being tested doesn't fall in the first page. For
this to work I think we need to mask offset + 8 the way it's done for
the check line 332.

Note that the comment says addresses are 48 bits but the one I see is 56
bits. No sure if that means addresses can be larger than 48 bits?

Roland.