速すぎ、大きすぎます：Javaでのメソッド呼び出しのパフォーマンスに影響を与えるものは何ですか？

翻訳者から：

どこでも最終的な執筆の支持者と彼らの反対者の間の論争は、先の尖ったそして鈍いの議論に似ています。 他の一部のコミュニティと同様に、当社ではこの低迷する紛争が何年も続いています。 そして、リチャード・ウォーバートンによるこの記事だけが、天才が優位に立つことを可能にしました。

何言ってるの？

短い話から始めましょう。 数週間前に、いくつかのメソッドから最終修飾子を削除するために、Javaコアライブラリメーリングリストに提案を送りました。 その結果、議論のためのいくつかのトピックが発生しました。 たとえば、そのうちの1つは、 ファイナルが削除された場合、 ファイナルだったメソッドの呼び出しのパフォーマンスがどの程度低下するかを調べることです。



パフォーマンスの低下が発生するかどうかについていくつか考えましたが、最初に、この問題に関するベンチマーク結果を既に公開している人がいないかどうかを確認しようとしました。 残念ながら、何も見つかりませんでした。 これは、それらが存在しないことや他の人が状況を調査しなかったことを意味するものではありませんが、専門家のレビューに合格したコードは見ませんでした。 それでは、いくつかのベンチマークを作成します。

ベンチマーク方法論

そこで、ベンチマークにすばらしいJMHフレームワークを使用することにしました。 フレームワークが正確なベンチマーク結果を得るのに役立つかどうか確信がない場合は、フレームワークの作者であるAlexey Shipilev（@TheShade）、またはこれがどのように役立つかを説明する本当にクールなNitsan Wakartブログ によるこのプレゼンテーションを ご覧ください 。



私の場合、メソッド呼び出しのパフォーマンスに影響を与えたものを理解したかったのです。 メソッド呼び出しのさまざまなバリエーションを試して、それらのコストを測定することにしました。 一連の基準を持ち、一度に1つの要因のみを変化させることで、さまざまな要因またはそれらの組み合わせがメソッド呼び出しのコストにどのように影響するかを理解できます。

インライン化

同時に、最も明白な影響要因は、メソッドがまったく呼び出されるかどうかです。 実際のメソッド呼び出しは、コンパイラーによって非常に最適化されるため、まったく残っていません。 一般的に、通話のコストを削減するには2つの方法があります。 1つはメソッド自体を直接埋め込むことで、もう1つはインラインキャッシュを使用することです。 心配しないでください-これらは非常に単純な概念ですが、整理すべき用語が少しあります。 barと呼ばれるメソッドを定義するFooと呼ばれるクラスがあると想像してください。

class Foo { void bar() { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようなコードを記述することで、barメソッドを呼び出すことができます。

 Foo foo = new Foo(); foo.bar();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの主なものは、barが実際に呼び出される場所です-foo.bar（）- Callsiteと呼ばれます 。 メソッドがインライン（ビルトイン）であると言うとき、これはメソッドを呼び出す代わりにメソッドの本体が取得され、コールサイトに挿入されることを意味します。 多くの小さなメソッドで構成されるプログラムの場合（プログラムを作成する方が正しいと思います）、埋め込みを行うと大幅に高速化できます。 これは、プログラムが作業を行う代わりにメソッド呼び出しにほとんど時間を費やさないためです！ CompilerControlアノテーションを使用して、メソッドがJMHに組み込まれているかどうかを制御できます。 インラインキャッシュの概念に少し戻ります。

階層の深さとメソッドの再定義

メソッドから最終キーワードを削除することにした場合、これはそれをオーバーライドできることを意味します。 これも考慮すべき要素です。 そのため、メソッドを取得し、クラス階層のさまざまなレベルでメソッドを呼び出しました。 階層のさまざまなレベルで再定義されたメソッドもありました。 これにより、クラス階層とメソッドオーバーライドとの相互作用の程度を判断できました。

多型

前にコールサイトのアイデアについて言及したとき、私はひそかにかなり重要な質問を回避したかった。 非最終メソッドはサブクラスでオーバーライドできるため、呼び出しサイトはさまざまなメソッドを呼び出すことになります。 だから多分私はFooまたはその子クラスBazを扱っており、これもbar（）を実装しています。 コンパイラはどのメソッドを呼び出すかをどのように知るのですか？ Javaのすべてのメソッドはデフォルトで仮想（再定義可能）であり、呼び出しごとに、いわゆる仮想メソッドテーブル（vtable）で正しいメソッドを探す必要があります。 これはかなり遅いため、最適化コンパイラは常にそのような検索のコストを削減しようとします。 前述のアプローチ-インライン化または埋め込み-は、特定の呼び出しサイトが特定のメソッド実装を1つしか呼び出せないことをコンパイラが証明できる場合に、うまく機能します。 これは、単相コールサイトと呼ばれます。



残念ながら、ほとんどの場合、Callsiteが厳密に単相であることを証明することは最終的に非実用的です。 JITコンパイラは通常、コールサイトで呼び出される型をプロファイリングし、最初のNコールでコールサイトが単相である場合、常に単相であるという仮定に基づいた投機的最適化に値すると仮定して、代替アプローチを採用します。 このような投機的最適化は通常は正しいですが、常にそうとは限りません。 したがって、コンパイラは、メソッドを呼び出す前にセキュリティを実装して、メソッドが呼び出されるオブジェクトのタイプを確認する必要があります。



ただし、最適化を行うのは単相コールサイトだけではありません。 多くのコールサイトは、彼らが言うように、バイモーフィックです-すなわち。 呼び出すことができる2つのメソッドがあります。 セキュリティコードを使用してバイモーフィックコールサイトを埋め込み、どの実装を呼び出すかを確認してから続行できます。 これは、完全なメソッド呼び出しよりも安価です。 さらに、インラインキャッシュを使用してこのケースを最適化できます。 インラインキャッシュは実際にはメソッドの本体を呼び出しサイトに埋め込みませんが、仮想メソッドの完全なテーブルのキャッシュのように機能する特別なブランチテーブルを持っています。 Hotspot JITコンパイラはバイモーフィックの組み込みキャッシュをサポートし、3つ以上の実装が可能なコールサイトをメガモーフィックと見なします。



したがって、比較と研究では、3種類の呼び出しが区別されます。単相、バイモルフ、および大形の呼び出しの場合です。

結果

結果をグループ化して、木の中で森を見ることができます。 それらの少しの分析とともに、乾燥した数値を提示します。 特定の数/コストは、実際にはそれほど興味深いものではありません。 さまざまなタイプのメソッド呼び出し間の関係は興味深いので、統計誤差はわずかです。 最速と最遅の間にはかなり大きな違いがあります-6.26倍です。 実際には、空のメソッドの時間を測定することに関連するコストのため、この差はおそらくより大きくなります。



これらのベンチマークのソースコードはGitHubで入手できます 。 混乱を避けるため、結果の一部を異なるブロックで提示しました。 多態性ベンチマークは多態性ベンチマークを使用して作成され、残りはJavaFinalBenchmarkを使用して作成されます。

単純な呼び出し

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.finalInvoke avgt 25 2.606 0.007 ns/op cijJavaFinalBenchmark.virtualInvoke avgt 25 2.598 0.008 ns/op cijJavaFinalBenchmark.alwaysOverriddenMethod avgt 25 2.609 0.006 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の結果セットは、仮想メソッド、 最終メソッド、および深い階層に含まれて再定義されるメソッドを呼び出すコストを示しています。 これらのすべてのケースで、メソッドを埋め込まないようコンパイラーに強制したことに注意してください。 ご覧のとおり、時間の差はごくわずかであり、標準偏差はこれが重要ではないことを示しています。 したがって、 最終キーワードを追加するだけでは、通話パフォーマンスを大幅に向上させることはできないと結論付けることができます。 メソッドをオーバーライドしても大きな違いはないようです。

シンプルなコールサイトの埋め込み

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.inlinableFinalInvoke avgt 25 0.782 0.003 ns/op cijJavaFinalBenchmark.inlinableVirtualInvoke avgt 25 0.780 0.002 ns/op cijJavaFinalBenchmark.inlinableAlwaysOverriddenMethod avgt 25 1.393 0.060 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、同じ3つのケースを使用して、埋め込み制限を削除します。 繰り返しますが、 最終メソッドと仮想メソッドの呼び出しは同じ時間になります。 埋め込みの禁止の場合よりも4倍速く、実際に埋め込みにアカウントに書き込みます。 どこでもオーバーライドされたメソッドの呼び出しは、2つの間で終わります。 これは、メソッド自体にサブクラスの実装がいくつかあり、コンパイラが型チェックを挿入する必要があるためだと思われます。 この仕組みについては、「多態性」セクションで詳しく説明しています。

クラス階層の影響

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.parentMethod1 avgt 25 2.600 0.008 ns/op cijJavaFinalBenchmark.parentMethod2 avgt 25 2.596 0.007 ns/op cijJavaFinalBenchmark.parentMethod3 avgt 25 2.598 0.006 ns/op cijJavaFinalBenchmark.parentMethod4 avgt 25 2.601 0.006 ns/op cijJavaFinalBenchmark.inlinableParentMethod1 avgt 25 1.373 0.006 ns/op cijJavaFinalBenchmark.inlinableParentMethod2 avgt 25 1.368 0.004 ns/op cijJavaFinalBenchmark.inlinableParentMethod3 avgt 25 1.371 0.004 ns/op cijJavaFinalBenchmark.inlinableParentMethod4 avgt 25 1.371 0.005 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

うわー、これはメソッドの大きなブロックです！ 番号付きのメソッド呼び出し（1〜4）のそれぞれは、メソッドがクラス階層のどのくらい深く呼び出されたかを示しています。 したがって、parentMethod4は、4番目の親クラスで宣言されたメソッドを呼び出すことを意味します。 数字を見ると、1と4の差は非常に小さいです。 したがって、階層の深さは重要ではないと結論付けることができます。 埋め込み時には、全員が同じパターンに従います。階層の深さは関係ありません。 インラインメソッドのパフォーマンスはinlinableAlwaysOverriddenMethodに匹敵しますが、inlinableVirtualInvokeよりも低速です。 私は再びこれを型チェックに帰するでしょう。 JITコンパイラーはメソッドをプロファイルして、1つだけが組み込まれていることを確認できますが、常にそうであると証明することはできません。

クラス階層がfinalメソッドに与える影響

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.parentFinalMethod1 avgt 25 2.598 0.007 ns/op cijJavaFinalBenchmark.parentFinalMethod2 avgt 25 2.596 0.007 ns/op cijJavaFinalBenchmark.parentFinalMethod3 avgt 25 2.640 0.135 ns/op cijJavaFinalBenchmark.parentFinalMethod4 avgt 25 2.601 0.009 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod1 avgt 25 1.373 0.004 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod2 avgt 25 1.375 0.016 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod3 avgt 25 1.369 0.005 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod4 avgt 25 1.371 0.003 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記と同じスキームです- 最終的なキーワードには意味がないようです。 ここでは、inlinableParentFinalMethod4が埋め込み可能であり、型チェックを除外していることを理論的に証明できると考えましたが、そうではないようです。

多型

 Monomorphic: 2.816 +- 0.056 ns/op Bimorphic: 3.258 +- 0.195 ns/op Megamorphic: 4.896 +- 0.017 ns/op Inlinable Monomorphic: 1.555 +- 0.007 ns/op Inlinable Bimorphic: 1.555 +- 0.004 ns/op Inlinable Megamorphic: 4.278 +- 0.013 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に、ポリモーフィックチャレンジのケースについて説明します。 大まかに言って、単相呼び出しのコストは、前述の通常の仮想呼び出しのコストと同じです。 仮想メソッドの大きなテーブルを検索する必要があるため、生物型およびメガモルフィックのケースが出現するにつれて、それらは遅くなります。 埋め込みを有効にするとすぐに、プロファイリングは不要になり、単相および生物型のコールサイトは、型チェックを使用した組み込みコールのコストになります。 クラス階層の場合と非常に似ていますが、少し遅くなります。 メガモルフィックなケースは依然として非常に遅いです。 ここで、埋め込みを防ぐためにHotspotを設定しなかったことを思い出してください。これは、バイモルフよりも複雑なコールサイトのポリモーフィックインラインキャッシュを実装しません。

私たちは何を理解していますか？

さまざまなタイプのメソッド呼び出しを計算し、さまざまな時間をかける生産性の投機的モデルを持っていない人や、さまざまな時間を使用していることを理解しているが実際には理解していない人が多いことに注意する価値があると思いますそうです 私自身がそうであり、間違った仮定をしたためです。 ですから、この研究があなたの役に立つことを願っています。 以下は、私がこの記事で提唱した論文の概要です。

• メソッド呼び出しの最速タイプと最遅タイプには大きな違いがあります。
• 実際には、 最終キーワードを追加または削除しても実際にはパフォーマンスには影響しませんが、後で階層を再編成すると、プロセスの速度が低下し始める場合があります。
• より深いクラス階層は、通話パフォーマンスに実際の影響を与えません。
• 単相呼び出しは、バイモルフ呼び出しよりも高速です。
• バイモルフコールは、メガモーフィックコールよりも高速です。
• プロファイリングの場合に見られるタイプをチェックするとき、単相性を証明することが不可能なとき、単相性と比較して呼び出しは少し遅くなります。

型チェックの価格は私の個人的な「大きな啓示」だと思います。 これはめったに議論されず、しばしば無視されていると私が見ているものです。

注意と追加作業

もちろん、これがこの問題に対する唯一の可能なアプローチではありません！

• この記事では、呼び出しタイプに関連するメソッド呼び出しのパフォーマンスに影響する要因に焦点を当てます。 私が言及しなかった1つの要因は、呼び出しスタックのサイズまたは深さに応じて埋め込まれているメソッドを取り巻くヒューリスティックです。 メソッドが大きすぎる場合、メソッドはまったく埋め込まれず、メソッドを呼び出すための費用を支払うことになります。 小さく、読みやすいメソッドを記述するもう1つの理由。
• インターフェイスを介した呼び出しがこれらの状況にどのように影響するかについては検討していません。 これがおもしろいと思う場合は、 Mechanical Sympathy Blogにインターフェースのパフォーマンス調査があります。
• 完全に無視した要因の1つは、他のコンパイラ最適化に対する埋め込みメソッドの効果です。 コンパイラーが最適化を実行する場合、1つのメソッドのみが分析され（プロセス内最適化）、効果的な最適化のためには、可能な限り多くの情報が本当に必要です。 埋め込みを制限すると、他の最適化で動作する必要のあるコンテキストを大幅に減らすことができます。
• この問題をより詳細に掘り下げるために、説明をアセンブラーのレベルにリンクします。

おそらく、これらは今後の投稿のトピックです。



謝辞：

-Alexey Shipilev 、ベンチマークへのフィードバック、

-Martin Thompson 、Martijn Verburg、Sadiq Jaffer、 Chris Westのユーザーへ-私のブログで非常に役立つフィードバックとコメントを。