【译】JVM Anatomy Park #15: 即时常量

原文地址：JVM Anatomy Park #15: Just-In-Time Constants

问题

当然，优化器可以利用程序中的常量。JVM 有优化么？

理论

当然，基于常量的优化是最有效的优化。在编译的时候处理完，运行时就不需要处理了，这是无法超越的优化方式。但是什么是常量？看起来普通字段不是常量：它们随时都可能改变。那么final字段呢？它们是不变的。但是，因为实例字段是对象状态的一部分，所以final 实例字段的值也依赖对象的身份：

class M {
  final int x;
  M(int x) { this.x = x; }
}

M m1 = new M(1337);
M m2 = new M(8080);

void work(M m) {
  return m.x; // what to compile in here, 1337 or 8080?
}

因此，这是理所当然的，如果我们在不知道参数对象身份的情况下编译方法 work ^[1]，那么我们唯一可以相信的是static final 字段：由于final所以是不可变的，另外我们确定知道“持有对象”的身份，因为它是由类持有的，而不是个别的对象。

我们可以从实践中观察么？

实践

考虑这个 JMH 测试用例：

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(3)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class JustInTimeConstants {

    static final long x_static_final = Long.getLong("divisor", 1000);
    static       long x_static       = Long.getLong("divisor", 1000);
           final long x_inst_final   = Long.getLong("divisor", 1000);
                 long x_inst         = Long.getLong("divisor", 1000);

    @Benchmark public long _static_final() { return 1000 / x_static_final; }
    @Benchmark public long _static()       { return 1000 / x_static;       }
    @Benchmark public long _inst_final()   { return 1000 / x_inst_final;   }
    @Benchmark public long _inst()         { return 1000 / x_inst;         }

}

这个测试用例经过精心的构建，使得编译器可以利用除数是常量这一事实，进行除法优化。如果我们执行测试用例，那么结果将类似这样：

Benchmark                          Mode  Cnt  Score   Error  Units
JustInTimeConstants._inst          avgt   15  9.670 ± 0.014  ns/op
JustInTimeConstants._inst_final    avgt   15  9.690 ± 0.036  ns/op
JustInTimeConstants._static        avgt   15  9.705 ± 0.015  ns/op
JustInTimeConstants._static_final  avgt   15  1.899 ± 0.001  ns/op

使用 -prof perfasm探究测试用例中最热的指令，这将会揭示一些实现细节，以及为什么某些测试更快的原因。

_inst 与 _inst_final 的结果在意料之内：程序读取字段，然后做为除数。大部分时钟周期耗费在整数除法：

# JustInTimeConstants._inst / _inst_final hottest loop
0.21%              mov    0x40(%rsp),%r10
0.02%            │  mov    0x18(%r10),%r10    ; get field x_inst / x_inst_final
                 |  ...
0.13%            │  idiv   %r10               ; ldiv
76.59%   95.38%  │  mov    0x38(%rsp),%rsi    ; prepare and consume the value (JMH infra)
0.40%            │  mov    %rax,%rdx
0.10%            │  callq  CONSUME
                 |  ...
1.51%            │  test   %r11d,%r11d        ; call @Benchmark again
                 ╰  je     BACK

_static 的结果比较有趣：程序从静态字段驻留的本地类镜像读取数据。因为运行时知道当前在处理哪个类（静态字段访问是静态解析的！），所以我们内联常量指针到镜像，通过预定义的偏移量访问字段。但是，因为我们不知道字段的值是什么 —— 代码生成之后字段的值可以修改 —— 所以仍然需要做相同的整数除法：

# JustInTimeConstants._static hottest loop
0.04%              movabs $0x7826385f0,%r10  ; native mirror for JustInTimeConstants.class
0.02%            │  mov    0x70(%r10),%r10    ; get static x_static
                 |  ...
0.02%            │  idiv   %r10               ;*ldiv
72.78%   95.51%  |  mov    0x38(%rsp),%rsi    ; prepare and consume the value (JMH infra)
0.38%            │  mov    %rax,%rdx
0.04%    0.06%   │  data16 xchg %ax,%ax
         0.02%   │  callq  CONSUME
                 |  ...
0.13%            │  test   %r11d,%r11d        ; call @Benchmark again
                 ╰  je     BACK

_static_final 的结果是最有趣的。JIT 编译器精确知道要处理的数值，所以可以激进地优化。因此循环计算只是重用预计算的值即可，"1000 / 1000"也就是是”1“^[2]：

# JustInTimeConstants._static_final hottest loop
1.36%    1.40%     mov    %r8,(%rsp)
7.73%    7.40%   │  mov    0x8(%rsp),%rdx       ; <--- slot holding the "long" constant "1"
0.45%    0.51%   │  mov    0x38(%rsp),%rsi      ; prepare and consume the value (JMH infra)
3.59%    3.24%   │  nop
1.44%    0.54%   │  callq  CONSUME
                 | ...
3.46%    2.37%   │  test   %r10d,%r10d          ; call @Benchmark again
                 ╰  je     BACK

所以性能可以用编译器通过 static final 常量化的能力解释。

观察

注意在这个例子中，字节码编译器（例如 javac）不知道 static final 字段的值，因为这个字段是由运行时值初始化的。当 JIT 编译开始的时候，类已经成功的初始化了，数值已经确定了，所以就可以利用了！这实际上是即时常量。这样就可以开发非常高效，但是运行时可调的代码：实际上，整个过程可以被认为是基于预处理器的断言的替换。^[3]我经常会忘记 C++ 中这种技巧，在 C++ 中编译全部都是提前的，因此如果你想要关键代码依赖运行时选项，那么你必须具有创造性。^[4]

其中很重要的部分是解释器和分层编译。类初始化器通常是冷代码，因为它们只执行一次。但是，当我们加载和初始化类，第一次访问字段的时候，更重要的是处理类初始化中“懒加载”的部分。解释器或者基准 JIT 编译器（比如 Hotspot 中的 C1）将会处理这些。当优化 JIT 编译器（比如 Hotspot 中的 C2）执行相同的方法时，重新编译的方法所需要的类已经完全初始化了，其中static final字段已经明确知道值了。

---

[1] 这里不排除基于流的优化，比如调用内联的work(new M(4242))

[2] 用 int 替换 long 做相同的测试将会输出 mov $0x1, %edx，但是我懒得重新格式化所有列出的汇编代码。

[3] 这并不是完全奏效，因为默认的内联启发式算法仍然需要考虑方法的字节码长度，而不管其中有多少死代码。这个问题将通过增量内联等逐步改善。

[4] 这几乎不可避免的转变为模板或者元编程，我们喜欢编写，但是讨厌调试。