[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