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

[Andrew Haley]

On 22/06/17 16:42, Roland Westrelin wrote:
> 
> 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.

Presumably this isn't a patchable address, so it's emitted as a simple
integer constant?  If it's of the correct type, we should output it as
mov(reg, address).  This will not change size.

> 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?

They can't.  48 bits is correct.

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