[aarch64-port-dev ] Bug in assembler MacroAssembler::check_klass_subtype_slow_path affects JDK7 and JDK8 (and JDK9?)

[Andrew Dinn]

If UseCompressedOops is true then MacroAssembler method
check_klass_subtype_slow_path() feeds a subclass count into repne_scanw
as follows:

  . . .
  // We will consult the secondary-super array.
  ldr(r5, secondary_supers_addr);
  // Load the array length.  (Positive movl does right thing on LP64.)
  ldr(r2, Address(r5, arrayOopDesc::length_offset_in_bytes()));
  // Skip to start of data.
  add(r5, r5, arrayOopDesc::base_offset_in_bytes(T_OBJECT));

  // This part is tricky, as values in supers array could be 32 or 64
bit wide
  // and we store values in objArrays always encoded, thus we need to encode
  // the value of r0 before repne.  Note that r0 is dead after the repne.
  if (UseCompressedOops) {
    encode_heap_oop_not_null(r0); // Changes flags.
    cmp(sp, zr); // Clear Z flag; SP is never zero
    repne_scanw(r5, r0, r2, rscratch1);
  } else {
  . . .

However, as is clear from the x86 code the ldr into r2 should only be
loading an int not a long:

  . . .
  // We will consult the secondary-super array.
  movptr(rdi, secondary_supers_addr);
  // Load the array length.  (Positive movl does right thing on LP64.)
  movl(rcx, Address(rdi, arrayOopDesc::length_offset_in_bytes()));
  // Skip to start of data.
  addptr(rdi, arrayOopDesc::base_offset_in_bytes(T_OBJECT));
  . . .
When I hit the slow path code booting up the JDK7 backport it caused
repne_scanw to use count 0xe08ebdd500000002 instead of count 0x00000002
slowing down progress somewhat :-). I don't know why this has never
caused a problem for jdk8 but it needs fixing in that tree as well as in
the jdk7 code. Probably also in JDK9?

regards,


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