性能说明：预热后代码运行较慢

一尘不染

性能说明：预热后代码运行较慢

java

下面的代码运行完全相同的计算3次（执行不大：基本上将1到100m的所有数字相加）。前两个块的运行速度大约比第三个块快10倍。我已经运行了该测试程序十次以上，结果显示出很小的差异。

如果有的话，我希望第三个块运行得更快（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;
}
```
}

阅读 191

2020-12-03

共1个答案

一尘不染

简短：即时编译器很笨。

首先，您可以使用该选项-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

因此，您看到有时在第一个和第二个块中编译了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)

（实际上，由于循环的展开和内联，它非常长）

显然在main的重新编译过程中，第二个AND第三个块将被编译。那里的第二个块看起来与第一个版本非常相似。（仅摘录）

 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

但是第三个块的编译方式不同。无需内联和展开

这次，整个循环如下所示：

  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识别出这部分代码没有使用太多，因为它使用了第二个块执行中的性能分析信息，因此并未对其进行大量优化。而且，在所有相关部分都已编译之后，不重新编译一种方法，JIT似乎很懒。请记住，第一个编译结果根本不包含第二个/第三个块AT的源代码，因此JIT必须重新编译它。

2020-12-03