Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8054307 JEP 254: Compact Strings
  3. JDK-8138690

String.charAt blows the MaxInlineSize limit, penalizes C1

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None

      Description

      While following up where the rest of the performance hits lies in C1 for String.charAt after C1 intrinsics arrived, I realized that we blow the static inlining thresholds for C1 when trying to inline String.charAt() -- the method is 73 bytes, while the threshold is 35 bytes.

      Unfortunately, massaging the code so it is works fine with both C1 and C2 yields a somewhat odd (all right, borderline horrible) peeling of charAt, but with tremendous boosts on C1:
        http://cr.openjdk.java.net/~shade/8138690/charat-c1-peeling.txt

      Alas, moving the range checks into String(Latin1|UTF16) would not really help, since we would need to peel out OOBE thrower there anyway. It will also require materializing the checks in intrinsics.

      Or, we might shrug it off, and let users know that -XX:MaxInlineSize=74 or more is needed to recover from the performance regression. C2 avoids this by inlining charAt as hot method, since -XX:FreqInlineSize is 325 bytes by default.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              shade Aleksey Shipilev
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: