[aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo() may return incorrect result

[Pengfei Li]

Hi,

Can any committer help push this fix? http://cr.openjdk.java.net/~pli/rfr/8237524/webrev.00/

Patch is reviewed by aph. See below review thread.

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Tuesday, January 21, 2020 18:13
> To: Nick Gasson <Nick.Gasson at arm.com>; Pengfei Li <Pengfei.Li at arm.com>;
> hotspot-compiler-dev at openjdk.java.net; aarch64-port-
> dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: Re: [aarch64-port-dev ] RFR(S): 8237524: AArch64:
> String.compareTo() may return incorrect result
> 
> On 1/21/20 10:11 AM, Nick Gasson wrote:
> > On 21/01/2020 17:33, Andrew Haley wrote:
> >> On 1/21/20 8:40 AM, Pengfei Li wrote:
> >>> 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.
> >>
> >> Is this really a bug? The test case is violating the protections
> >> provided by the Java runtime, and the programmer deserves everything
> >> that happens.
> >
> > Even if it's not strictly a bug, the pointer equality checks in the
> > LU/UL branches are unnecessary: the only time they succeed is when the
> > Strings were constructed in this backdoor way, and in that case they
> > give the wrong result. So it seems better to just remove them.
> 
> True enough; OK.
> 

Thanks,
Pengfei