[aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo() may return incorrect result
Andrew Haley
aph at redhat.com
Tue Jan 21 10:12:34 UTC 2020
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.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-compiler-dev
mailing list