19

以下のコードは、まったく同じ計算を 3 回実行します (大したことはありません。基本的には 1 から 100m までのすべての数値を加算します)。最初の 2 つのブロックは、3 番目のブロックよりも約 10 倍速く実行されます。このテスト プログラムを 10 回以上実行しましたが、結果の差異はほとんどありません。

どちらかといえば、3 番目のブロックがより高速に実行される (JIT コンパイル) ことを期待しますが、典型的な出力は次のとおりです。

35974537
36368455
296471550

誰かが何が起こっているのか説明できますか? (明確にするために、ここで何かを修正しようとしているわけではなく、何が起こっているのかをよりよく理解しようとしているだけです)

ノート:

  • プログラム中にGCは実行されません(で監視されます-XX:+PrintGC
  • Oracle JDK バージョン 1.6.0_30、1.7.0_02、および 1.7.0_05 でテスト済み
  • 次のパラメータでもテストされています: -XX:+PrintGC -Xms1000m -Xmx1000m -XX:NewSize=900m=> 同じ結果
  • 代わりにブロックがループに入れられると、すべての実行が高速になります
  • ブロックがメソッドに抽出された場合、すべての実行が高速です (メソッドが 3 回呼び出されても、ループで呼び出されても違いはありません)。
public static void main(String... args) {
    //three identical blocks
    {
        long start = System.nanoTime();
        CountByOne c = new CountByOne();
        int sum = 0;
        for (int i = 0; i < 100000000; i++) {
            sum += c.getNext();
        }
        if (sum != c.getSum()) throw new IllegalStateException(); //use sum
        long end = System.nanoTime();
        System.out.println((end - start));
    }
    {
        long start = System.nanoTime();
        CountByOne c = new CountByOne();
        int sum = 0;
        for (int i = 0; i < 100000000; i++) {
            sum += c.getNext();
        }
        if (sum != c.getSum()) throw new IllegalStateException(); //use sum
        long end = System.nanoTime();
        System.out.println((end - start));
    }
    {
        long start = System.nanoTime();
        CountByOne c = new CountByOne();
        int sum = 0;
        for (int i = 0; i < 100000000; i++) {
            sum += c.getNext();
        }
        if (sum != c.getSum()) throw new IllegalStateException(); //use sum
        long end = System.nanoTime();
        System.out.println((end - start));
    }
}

public static class CountByOne {

    private int i = 0;
    private int sum = 0;

    public int getSum() {
        return sum;
    }

    public int getNext() {
        i += 1;
        sum += i;
        return i;
    }
}
4

2 に答える 2

11

短い: ジャスト イン タイム コンパイラは馬鹿げています。

まず、このオプション-XX:+PrintCompilationを使用して、JIT が何かを実行しているときを確認できます。次に、次のようなものが表示されます。

$ java -XX:+PrintCompilation weird
    168    1             weird$CountByOne::getNext (28 bytes)
    174    1 %           weird::main @ 18 (220 bytes)
    279    1 %           weird::main @ -2 (220 bytes)   made not entrant
113727636
    280    2 %           weird::main @ 91 (220 bytes)
106265475
427228826

したがって、最初のブロックと 2 番目のブロックの間に、メソッド main が時々コンパイルされることがわかります。

オプションを追加する-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptionと、JIT が行っていることに関する詳細情報が得られます。hsdis-amd64.so一般的な Linux ディストリビューションではあまり利用できないと思われるものを必要とすることに注意してください。OpenJDK から自分でコンパイルする必要があるかもしれません。

得られるのは、getNext と main のアセンブラー コードの膨大なチャンクです。

私にとって、最初のコンパイルでは、main の最初のブロックだけが実際にコンパイルされているように見えます。行番号でわかります。次のようなおかしな内容が含まれています。

  0x00007fa35505fc5b: add    $0x1,%r8           ;*ladd
                                                ; - weird$CountByOne::getNext@6 (line 12)
                                                ; - weird::main@28 (line 31)
  0x00007fa35505fc5f: mov    %r8,0x10(%rbx)     ;*putfield i
                                                ; - weird$CountByOne::getNext@7 (line 12)
                                                ; - weird::main@28 (line 31)
  0x00007fa35505fc63: add    $0x1,%r14          ;*ladd
                                                ; - weird::main@31 (line 31)

(実際、ループの展開とインライン化のため、非常に長くなります)

どうやらメインの再コンパイル中に、2 番目と 3 番目のブロックがコンパイルされます。そこにある 2 番目のブロックは、最初のバージョンと非常によく似ています。(またもや抜粋です)

 0x00007fa35505f05d: add    $0x1,%r8           ;*ladd
                                                ; - weird$CountByOne::getNext@6 (line 12)
                                                ; - weird::main@101 (line 42)
  0x00007fa35505f061: mov    %r8,0x10(%rbx)     ;*putfield i
                                                ; - weird$CountByOne::getNext@7 (line 12)
                                                ; - weird::main@101 (line 42)
  0x00007fa35505f065: add    $0x1,%r13          ;*ladd

ただし、3 番目のブロックのコンパイル方法は異なります。インライン展開と展開なし

今回は、ループ全体は次のようになります。

  0x00007fa35505f20c: xor    %r10d,%r10d
  0x00007fa35505f20f: xor    %r8d,%r8d          ;*lload
                                                ; - weird::main@171 (line 53)
  0x00007fa35505f212: mov    %r8d,0x10(%rsp)
  0x00007fa35505f217: mov    %r10,0x8(%rsp)
  0x00007fa35505f21c: mov    %rbp,%rsi
  0x00007fa35505f21f: callq  0x00007fa355037c60  ; OopMap{rbp=Oop off=580}
                                                ;*invokevirtual getNext
                                                ; - weird::main@174 (line 53)
                                                ;   {optimized virtual_call}
  0x00007fa35505f224: mov    0x8(%rsp),%r10
  0x00007fa35505f229: add    %rax,%r10          ;*ladd
                                                ; - weird::main@177 (line 53)
  0x00007fa35505f22c: mov    0x10(%rsp),%r8d
  0x00007fa35505f231: inc    %r8d               ;*iinc
                                                ; - weird::main@180 (line 52)
  0x00007fa35505f234: cmp    $0x5f5e100,%r8d
  0x00007fa35505f23b: jl     0x00007fa35505f212  ;*if_icmpge
                                                ; - weird::main@168 (line 52)

私の推測では、JIT はコードのこの部分があまり使用されていないことを特定しました。これは、2 番目のブロック実行からのプロファイリング情報を使用していたため、あまり最適化されていなかったためです。また、関連するすべての部分がコンパイルされた後に 1 つのメソッドを再コンパイルしないという点で、JIT は怠惰に見えます。最初のコンパイル結果には 2 番目または 3 番目のブロックのソース コードがまったく含まれていなかったため、JIT はそれを再コンパイルする必要があったことを思い出してください。

于 2012-08-20T16:23:53.057 に答える
2

各ループを異なるメソッドに配置する必要があります。これを行う必要があるのは、JIT がコードの実行方法に関する統計を収集し、これを使用してコードを最適化するためです。ただし、メソッドは 10000 回呼び出された後、またはループが 10000 回実行された後に最適化されます。

あなたの場合、最初のループはメソッド全体を最適化するようにトリガーしますが、後のループは実行されていないため、統計は収集されていません。各ループを独自のメソッドに配置すると、これは発生しません。

于 2012-08-20T19:47:09.467 に答える