65要素の配列を宣言するよりも1000倍速く64要素の複数の配列を宣言する

最近、64要素を含む配列を宣言すると、65要素を含む同じタイプの配列を宣言するよりもはるかに高速（> 1000倍）であることに気付きました。

これをテストするために使用したコードは次のとおりです。

public class Tests{
    public static void main(String args[]){
        double start = System.nanoTime();
        int job = 100000000;//100 million
        for(int i = 0; i < job; i++){
            double[] test = new double[64];
        }
        double end = System.nanoTime();
        System.out.println("Total runtime = " + (end-start)/1000000 + " ms");
    }
}

これは約6ミリ秒で実行されます。これを置き換えるnew double[64]とnew double[65]、約7秒かかります。この問題は、ジョブがますます多くのスレッドに分散している場合に、指数関数的にさらに深刻になります。

この問題は、int[65]またはなどのさまざまなタイプの配列でも発生しますString[65]。この問題は大きな文字列では発生しません：String test = "many characters";に変更すると発生しますString test = i + "";

なぜこれが事実であり、この問題を回避することが可能であるかと思っていました。

Java VMのJITコンパイラーによって行われた最適化によって引き起こされる動作を観察しています。この動作は、64要素までのスカラー配列で再現的にトリガーされ、64より大きい配列ではトリガーされません。

詳細に入る前に、ループの本体を詳しく見てみましょう。

double[] test = new double[64];

ボディは影響を与えません（観察可能な動作）。つまり、このステートメントが実行されるかどうかにかかわらず、プログラムの実行以外では違いはありません。同じことがループ全体にも当てはまります。そのため、コードオプティマイザがループを同じ機能と異なるタイミング動作で何か（または何も）に変換する場合があります。

ベンチマークについては、少なくとも次の2つのガイドラインに従う必要があります。そうした場合、差は大幅に小さくなります。

• ベンチマークを数回実行して、JITコンパイラ（およびオプティマイザ）をウォームアップします。
• すべての式の結果を使用して、ベンチマークの最後に出力します。

それでは詳細に進みましょう。当然のことながら、64要素以下のスカラー配列に対してトリガーされる最適化があります。最適化は、エスケープ分析の一部です。小さなオブジェクトと小さな配列をヒープに割り当てるのではなく、スタックに配置します。あるいは、それらを完全に最適化して削除します。これに関するいくつかの情報は、2005年に書かれたBrian Goetzによる次の記事にあります。

• 再考された都市のパフォーマンスの伝説：割り当てはあなたが思っているよりも速く、より速くなっています

最適化は、コマンドラインオプションで無効にできます-XX:-DoEscapeAnalysis。スカラー配列のマジック値64は、コマンドラインでも変更できます。次のようにプログラムを実行する場合、64要素と65要素の配列に違いはありません。

java -XX:EliminateAllocationArraySizeLimit=65 Tests

そうは言っても、そのようなコマンドラインオプションを使用しないことを強くお勧めします。それが現実的なアプリケーションに大きな違いをもたらすとは思えません。一部の疑似ベンチマークの結果に基づいてではなく、必要性を完全に確信している場合にのみ使用します。

オブジェクトのサイズに基づいて、差異が生じる可能性のある方法はいくつもあります。

nosidが述べたように、JITCはスタック上に小さな「ローカル」オブジェクトを割り当てている可能性があり（ほとんどの場合）、「小さな」配列のサイズカットオフは64要素にある可能性があります。

スタックへの割り当ては、ヒープへの割り当てよりも大幅に高速であり、さらに言えば、スタックをガベージコレクションする必要がないため、GCオーバーヘッドが大幅に削減されます。（そして、このテストケースの場合、GCオーバーヘッドは、合計実行時間の80〜90％になる可能性があります。）

さらに、値がスタックに割り当てられると、JITCは「デッドコードの除去」を実行し、その結果がnewどこでも使用されないことを確認し、失われる副作用がないことを確認した後、new操作全体を除去します。そして（今は空の）ループ自体。

JITCがスタック割り当てを行わない場合でも、特定のサイズよりも小さいオブジェクトを、大きいオブジェクトとは異なる方法で（たとえば、異なる「スペース」から）ヒープに割り当てることができます。（ただし、通常、これによってそれほど劇的なタイミングの違いが生じることはありません。）