Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8215100

AArch64: fix compareTo intrinsic with four-character Latin/Unicode

    Details

      Backports

        Description

        JTreg test java/util/Calendar/Bug8167273.java fails on
        AArch64. This test checks the consistency of the era names (e.g. AD/BC)
        between each locale in two different databases of locale information. It
        fails on AArch64 for the az_AZ_#Latn locale, but only when using tiered
        compilation (i.e. it passes with -Xcomp or -Xint).

        It fails because it can't find a particular key in a TreeMap, but if you
        dump out the contents of that TreeMap, the key is present but the tree
        is not sorted correctly. The root problem is String::compareTo returns a
        different value when running in the interpreter and when compiled (the
        compiled result is wrong).

        Here is a much simpler test that shows the problem:

          public class CompareTo {
            public static void main(String args[]) {
              final String[] strings = { "e.\u0259.", "y.e." };
              strings[0].compareTo(strings[1]);
              for (String s1 : strings) {
                for (String s2 : strings) {
                  System.out.println(s1.compareTo(s2));
                }
              }
            }
          }

        With -Xint you get the correct result "0 -20 20 0" but -Xcomp gives "0
        -707 20 0". It's caused by a bug in the compareTo intrinsic that's
        triggered when both arguments are four characters long but one is Latin1
        encoded and one is Unicode encoded. In that case the "Compare longwords"
        loop header (isLU or else branches) will branch to the TAIL_CHECK label
        with tmp1 (isLU) or tmp2 (isUL) uninitialized. The instructions after
        TAIL_CHECK assume tmp1 and tmp2 contain the final 64-bit words of each
        string, and use these to compute the difference between the final
        characters. In the LU/UL case this result is garbage.

        This was broken sometime between JDK 10 and 11.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  njian Ningsheng Jian
                  Reporter:
                  njian Ningsheng Jian
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: