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

Final String field values should be trusted as stable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b83

      Backports

        Description

        We have an UseImplicitStableValues option that enables treating some known VM fields as stable. However, for String.value, it does only seem to matter in GraphKit, and therefore only the targeted compiler optimizations benefit from this, not the normal Java code. This gets in the way with Compact String work, which has a new "byte coder" field, that participates in every hot method, e.g.:

            public int length() {
                return value.length >> coder;
            }

        This method is compiled normally, and so escapes the provisions of UseImplicitStableValues. When we ask for "someconstantstring".length(), the coder field would always be read. To solve this, we might want to mark all final String fields as stable. It is not sufficient, however, to put @Stable over them (even if @Stable was a public annotation), because one of the legitimate values for "coder" is zero, which is coincidentally the default value for byte field. Therefore, we might need to put final String fields to TrustFinalNonStaticFields exceptions, to fold every value of coder.

          Issue Links

            Activity

            Show
            shade Aleksey Shipilev added a comment - Webrev:   http://cr.openjdk.java.net/~shade/8134758/webrev.00/
            Hide
            shade Aleksey Shipilev added a comment - - edited
            Simple benchmark:
              http://cr.openjdk.java.net/~shade/8134758/ConstLengthBench.java

            Returns the performance of String.length() back to JDK 8 levels:

            # JDK 8u40:
            ConstLengthBench.cmp1 2.830 ± 0.031 ns/op
            ConstLengthBench.cmp2 2.811 ± 0.002 ns/op

            # JDK 9, Compact Strings, before:
            ConstLengthBench.cmp1 3.561 ± 0.093 ns/op
            ConstLengthBench.cmp2 3.513 ± 0.004 ns/op

            # JDK 9, Compact Strings, after:
            ConstLengthBench.cmp1 2.819 ± 0.015 ns/op
            ConstLengthBench.cmp2 2.810 ± 0.001 ns/op
            Show
            shade Aleksey Shipilev added a comment - - edited Simple benchmark:    http://cr.openjdk.java.net/~shade/8134758/ConstLengthBench.java Returns the performance of String.length() back to JDK 8 levels: # JDK 8u40: ConstLengthBench.cmp1 2.830 ± 0.031 ns/op ConstLengthBench.cmp2 2.811 ± 0.002 ns/op # JDK 9, Compact Strings, before: ConstLengthBench.cmp1 3.561 ± 0.093 ns/op ConstLengthBench.cmp2 3.513 ± 0.004 ns/op # JDK 9, Compact Strings, after: ConstLengthBench.cmp1 2.819 ± 0.015 ns/op ConstLengthBench.cmp2 2.810 ± 0.001 ns/op
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c530a118f715
            User: thartmann
            Date: 2015-09-02 10:26:18 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c530a118f715 User: thartmann Date: 2015-09-02 10:26:18 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c530a118f715
            User: lana
            Date: 2015-09-23 23:04:19 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c530a118f715 User: lana Date: 2015-09-23 23:04:19 +0000

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: