[aarch64-port-dev ] jdk7 port: Patch to avoid RMI stub generation failure when using the newly generated JVM

[Andrew Dinn]

I tweaked jdk/make/com/sun/jmx/Makefile during development so that it
used the bootstrap JVM to generate the RMI stubs. this was needed in
order to get the build to complete.

WHowever, when Ed tried to do a full build from scratch without this
tweak a weird heap alignment issue in jdk7 (but not present in jdk8)
caused an assert when trying to load the card table byte map base.

The heap alignment for the jdk7 JVM is 0x80000 and passing -Xms512M
-Xmx512M appears always to result in the base being allocated at an odd
multiple. Of course, that is exactly what the RMI stub generate command
passes, something I managed to miss.

The problem arises as follows. The card table base address, byte_map, is
aligned to 0x1000 but the base address _byte_map_base is computed as

  _byte_map_base = (byte_map - (heap_start >> 9))

i.e. it is aligned to min(0x1000, 0x80000 >> 9) = 0x400

n.b. the original heap alignment is determined by this definition at
gc_implementation/parallelScavenge/parallelScavengeHeap.hpp

  size_t intra_heap_alignment() const { return 64 * K * HeapWordSize; }

That has disappeared from jdk8.

The assert which Ed hit occurs in MacroAssembler::pd_patch_instruction
in file assembler_aarch64.cpp. The offset for a patched adrp instruction
is assumed always to be 0x0. This assert covers two cases where we
generate an adrp without a following ldr

in aarch64.ad:2589 in the encoding rule for aarch64_enc_mov_byte_map_base

     Register dst_reg = as_Register($dst$$reg);
     unsigned long off;
     __ adrp(dst_reg, ExternalAddress(page), off);
     assert(off == 0, "assumed offset == 0");

in c1_Runtime_aarch64.cpp:1235 in method
Runtime1::generate_code_for(StubID id, StubAssembler* sasm) when id ==
case g1_post_barrier_slow_id

         __ lsr(card_addr, card_addr, CardTableModRefBS::card_shift);
 	unsigned long offset;
 	__ adrp(rscratch1, cardtable, offset);
         __ add(card_addr, card_addr, rscratch1);
         __ ldrb(rscratch1, Address(card_addr, offset));

(n.b. no actual assert there)

Now in order to fix this we have two choices:

  change intra_heap_alignment() to ensure the correct alignment (we can
make this arch-specific so it only affects AArch64)

  change the code which generates the adrp to check the offset and, if
it is non-zero, to plant a following ldr.

n.b. the offset value will never change so with the latter option the
patching code still only needs to update the adrp, whether or not there
is a following ldr. We would need to change the assert so that it
allowed for a multiple of 0x400 offset but only when the address is for
the card table. In that case we ought also to assert that the next
instruction is indeed an ldr.

Personally I think choice 1 is simpler and better -- it is essentially
what JDK8 does. We lose a bit more heap but we avoid the possibility of
having to plant the trailing ldr after the adrp. Anyone have an opinion?

regards,


Andrew Dinn
-----------