Java里mode能不能做标识符_JVM 解剖公园(15): 即时常量

最新推荐文章于 2024-03-02 07:52:42 发布

深孵小秘书-红小白

最新推荐文章于 2024-03-02 07:52:42 发布

阅读量228

点赞数

文章标签： Java里mode能不能做标识符

本文链接：https://blog.csdn.net/weixin_32816563/article/details/114712223

版权

(给ImportNew加星标，提高Java技能)

编译：ImportNew/唐尤华

shipilev.net/jvm/anatomy-quarks/15-just-in-time-constants/

1. 写在前面

“JVM 解剖公园”是一个持续更新的系列迷你博客，阅读每篇文章一般需要5到10分钟。限于篇幅，仅对某个主题按照问题、测试、基准程序、观察结果深入讲解。因此，这里的数据和讨论可以当轶事看，不做写作风格、句法和语义错误、重复或一致性检查。如果选择采信文中内容，风险自负。

Aleksey Shipilёv，JVM 性能极客

推特 @shipilev

问题、评论、建议发送到 aleksey@shipilev.net"">aleksey@shipilev.net

2. 问题

在程序中使用常量可以实现优化，那么 JVM 在背后究竟做了哪些工作？

3. 理论

基于常量优化是最理想的：运行时没有开销，所有工作在编译时完成。常量是什么？普通字段的值经常变化，它们不是常量。那么 final 字段呢？它们的值保持不变。但是，由于对象状态包含实例字段，final 字段值取决于对象的标识符：

class M {

final int x;

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

}

M m1 = new M(1337);

M m2 = new M(8080);

int work(M m) {

return m.x; // 编译后的值是 1337 还是 8080?

}

译注：原文 void work(M m) 会报告编译错误，改为 int work(M m)。

如果不知道参数标识符，就无法确认 work 方法编译后的结果 ⁽¹⁾。唯一可以确定的是 static final 字段：加上了 final 标识，字段是不可变的；由于是类属性，而非对象持有，可以明确属性持有者的标识符。

(1) 基于流式调用也在此列，比如内联调用 work(new M(4242))。

能不能在实验结果中观察到这点？

4. 实验

看看下面这个 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 ; 获取字段 x_inst / x_inst_final

| ...

0.13% │ idiv %r10 ; ldiv

76.59% 95.38% │ mov 0x38(%rsp),%rsi ; 准备处理字段值 (JMH 框架)

0.40% │ mov %rax,%rdx

0.10% │ callq CONSUME

| ...

1.51% │ test %r11d,%r11d ; 再次调用 @Benchmark

╰ je BACK

_static 的情况更有趣：它从static 字段实际存储的本地 class 镜像中读取 static 字段。static 字段是静态解析的，因此 JVM 运行时能够知道实际处理的是哪个类。虽然可以为镜像做内联指针，通过预先定义的偏移量访问字段，但是不知道实际值。可能有人在生成后的代码对其进行了修改。我们仍然执行相同的整数除法：

# JustInTimeConstants._static hottest loop

0.04% ↗ movabs $0x7826385f0,%r10 ; JustInTimeConstants.class 的本地镜像

0.02% │ mov 0x70(%r10),%r10 ; 获取 static x_static

| ...

0.02% │ idiv %r10 ;*ldiv

72.78% 95.51% | mov 0x38(%rsp),%rsi ; 准备处理字段值 (JMH 框架)

0.38% │ mov %rax,%rdx

0.04% 0.06% │ data16 xchg %ax,%ax

0.02% │ callq CONSUME

| ...

0.13% │ test %r11d,%r11d ; 再次调用 @Benchmark

_static_final 的情况最有趣：JIT 编译器能够确切知道正在处理的值，因此可以积极对其进行优化。这里可以看到，循环计算时重用了预先计算好的值 “1”，即 “1000 / 1000” ⁽²⁾：

(2) 使用 int 相比 long 情况会生成 mov $0x1, %edx。但是我太懒了，这里就不再更新这种情况了。

# JustInTimeConstants._static_final hottest loop

1.36% 1.40% ↗ mov %r8,(%rsp)

7.73% 7.40% │ mov 0x8(%rsp),%rdx ;

0.45% 0.51% │ mov 0x38(%rsp),%rsi ; 准备处理字段值 (JMH 框架)

3.59% 3.24% │ nop

1.44% 0.54% │ callq CONSUME

| ...

3.46% 2.37% │ test %r10d,%r10d ; 再次调用 @Benchmark

╰ je BACK

通过上述分析，从编译器角度解释了 static final 常量的性能表现。

5. 观察

注意：在上面的例子中，由于因为该字段使用运行时中的值初始化，因此像 javac 这样的字节码编译器并不知道 static final 字段的具体值。JIT 编译时，类已经成功地初始化，可以随时使用字段值。这是真正的“实时常数”。这样可以开发出高效且可在运行时调整的代码：整个过程可以看作基于预处理断言的一种替代⁽³⁾。使用 C++ 时通常会忘记这种技巧，因为它是提前编译的。除非具备一定的创造性，才可能让关键代码使用运行时选项⁽⁴⁾。

(3) 这种方法并不会完全奏效。无论 dead code 有多少，默认的内联试探法都会按照字节码长度方式计算方法大小。类似增量内联这样的方法能够对这种情况有所改善。

(4) 这种方式几乎不可避免地会引起模板或元编程混乱。我们都喜欢写代码，但讨厌调试。

这里最重要的部分是解析器与分层编译。类初始化代码通常只执行一次。但更重要的是类初始化过程中延迟加载部分，第一次访问字段时加载类并执行初始化，解释器或基线 JIT 编译器(例如 Hotspot 中的 C1)会开始工作。当 JIT 优化编译器(例如 C2)开始对相同函数进行优化时，重新编译的方法通常会进行完整的初始化，并且 static final 字段的值全部确认。