RFR(S): 8237524: AArch64: String.compareTo() may return incorrect result

[Pengfei Li]

Hi,

Please help review this small fix on AArch64 string intrinsics.

JBS: https://bugs.openjdk.java.net/browse/JDK-8237524
Webrev: http://cr.openjdk.java.net/~pli/rfr/8237524/webrev.00/

AArch64 String.compareTo() may return incorrect result in some corner
cases. This issue can be reproduced in below program by constructing two
strings from the same byte array but with different encoding options.

--------

import java.lang.reflect.Constructor;

public class Test {
  public static void main(String[] args) throws Exception {
    Constructor<String> c = String.class.getDeclaredConstructor(byte[].class, byte.class);
    c.setAccessible(true);

    byte[] bytes = new byte[] {
      'Y', 'm', '_', 'l', 'V', 'n', 'W', 'S', 'w', 'm', 'W', 'S'
    };

    String s1 = c.newInstance(bytes, (byte) 0);
    String s2 = c.newInstance(bytes, (byte) 1);
    System.out.println(s1.compareTo(s2));
  }
}

// $ java -Xint Test
// -27904
// $ java -Xcomp -XX:-TieredCompilation Test
// 6

--------

Root cause is in the AArch64 String.compareTo intrinsics. In the code of
MacroAssembler::string_compare(), we have a fast path that compares the
addresses of initial bytes of the two arrays. If the result is equal, we
skip the inflation of the Latin one and the byte-wise comparison part.
But we shouldn't do in this way if the encodings of the two strings are
different (the LU/UL cases). This patch removes the incorrect fast path
check.

Tests:
No new failure found in hotspot::hotspot_all_no_apps, jdk::jdk_core,
langtools::tier1 after this patch. A new jtreg case is also added for
this issue.

--
Thanks,
Pengfei