StringBuilder#append(int) が Java 7 よりも Java 8 の方が速いのはなぜですか? 質問する

要約:副作用により、appendStringConcat の最適化が明らかに中断されます。

元の質問と更新の分析が非常に優れています。

完全を期すために、以下にいくつかの欠落した手順を示します。

• 7u55 と 8u5 の両方を参照してください-XX:+PrintInlining。7u55 では、次のようになります。

   @ 16   org.sample.IntStr::inlineSideEffect (25 bytes)   force inline by CompilerOracle
     @ 4   java.lang.StringBuilder::<init> (7 bytes)   inline (hot)
     @ 18   java.lang.StringBuilder::append (8 bytes)   already compiled into a big method
     @ 21   java.lang.StringBuilder::toString (17 bytes)   inline (hot)
  

  ...そして8u5では:

   @ 16   org.sample.IntStr::inlineSideEffect (25 bytes)   force inline by CompilerOracle
     @ 4   java.lang.StringBuilder::<init> (7 bytes)   inline (hot)
       @ 3   java.lang.AbstractStringBuilder::<init> (12 bytes)   inline (hot)
         @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
     @ 18   java.lang.StringBuilder::append (8 bytes)   inline (hot)
       @ 2   java.lang.AbstractStringBuilder::append (62 bytes)   already compiled into a big method
     @ 21   java.lang.StringBuilder::toString (17 bytes)   inline (hot)
       @ 13   java.lang.String::<init> (62 bytes)   inline (hot)
         @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
         @ 55   java.util.Arrays::copyOfRange (63 bytes)   inline (hot)
           @ 54   java.lang.Math::min (11 bytes)   (intrinsic)
           @ 57   java.lang.System::arraycopy (0 bytes)   (intrinsic)
  

  7u55 バージョンの方が浅く、メソッドの後に何も呼び出されていないように見えることに気付くかもしれません。StringBuilderこれは、文字列の最適化が有効になっていることを示す良い兆候です。実際、 で 7u55 を実行すると-XX:-OptimizeStringConcat、サブコールが再び表示され、パフォーマンスは 8u5 レベルまで低下します。

• さて、8u5が同じ最適化を行わない理由を理解する必要があります。GrepホットスポットVMがStringConcatの最適化をどこで処理するかを「StringBuilder」で調べます。これにより、src/share/vm/opto/stringopts.cpp

• hg log src/share/vm/opto/stringopts.cpp最新の変更点を把握するために、候補の 1 つは次のとおりです。

  changeset:   5493:90abdd727e64
  user:        iveresov
  date:        Wed Oct 16 11:13:15 2013 -0700
  summary:     8009303: Tiered: incorrect results in VM tests stringconcat...
  

• OpenJDK メーリング リストのレビュー スレッドを探します (変更セットの概要を Google で検索するのは簡単です)。http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-October/012084.html

• スポット「文字列連結最適化」は、パターンを [...] 文字列の単一の割り当てに縮小し、結果を直接形成します。最適化されたコードで発生する可能性のあるすべてのデオプトは、このパターンを最初から（StringBuffer の割り当てから開始して）再開します。つまり、パターン全体に副作用がない必要があります。「エウレカ？」

• 対照的なベンチマークを書き出します。

  @Fork(5)
  @Warmup(iterations = 5)
  @Measurement(iterations = 5)
  @BenchmarkMode(Mode.AverageTime)
  @OutputTimeUnit(TimeUnit.NANOSECONDS)
  @State(Scope.Benchmark)
  public class IntStr {
      private int counter;
  
      @GenerateMicroBenchmark
      public String inlineSideEffect() {
          return new StringBuilder().append(counter++).toString();
      }
  
      @GenerateMicroBenchmark
      public String spliceSideEffect() {
          int cnt = counter++;
          return new StringBuilder().append(cnt).toString();
      }
  }
  

• JDK 7u55 で測定すると、インライン化/スプライスされた副作用で同じパフォーマンスが見られます。

  Benchmark                       Mode   Samples         Mean   Mean error    Units
  o.s.IntStr.inlineSideEffect     avgt        25       65.460        1.747    ns/op
  o.s.IntStr.spliceSideEffect     avgt        25       64.414        1.323    ns/op
  

• JDK 8u5 で測定し、インライン効果によるパフォーマンスの低下を確認します。

  Benchmark                       Mode   Samples         Mean   Mean error    Units
  o.s.IntStr.inlineSideEffect     avgt        25       84.953        2.274    ns/op
  o.s.IntStr.spliceSideEffect     avgt        25       65.386        1.194    ns/op
  

• バグレポートを送信してください（参考:) にアクセスして、VM 担当者とこの動作について話し合いました。元の修正の根拠は確固たるものですが、このような些細なケースでこの最適化を復元できるかどうかは興味深いところです。

• ???

• 利益。