JDK-8138690 : String.charAt blows the MaxInlineSize limit, penalizes C1
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: compiler
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-10-01
  • Updated: 2015-10-02
  • Resolved: 2015-10-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
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.
Comments
Pushed: http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/079c46ba835e
02-10-2015