原文地址：JVM Anatomy Park #22: Safepoint Polls
问题
- JVM 如何停止 Java 线程以实现 stop-the-world？
- 在热循环中奇怪的
test指令是什么？ - 为什么在 Java 11 中空方法执行变慢了？
所有这些问题的答案是同一个。
理论
像 JVM 这种托管运行时系统，有时需要停止 Java 线程，执行一些运行时代码。比如，执行 stop-the-world GC。可以等待所有线程最终调用 JVM，比如申请内存（经常执行 TLAB 替换），或者类似的操作。但是这不一定会发生！如果线程正在执行某种频繁的循环逻辑而不做别的事情怎么办？
在大部分机器上停止运行的线程实际上是很简单的：向线程发送一个信号，强制处理器中断，等。停止线程正在执行的操作，将控制权转交给别处。然而，这还不足以让 Java 线程在任意位置停止，特别是如果你需要精确的垃圾回收。在这种情况下，你需要知道寄存器和栈中的内容，这些内容可能是你需要处理的对象引用。或者如果你想要取消偏向锁，你需要精确的知道线程的状态和获取的锁。或者如果你想要逆优化方法，你需要在不丢失执行状态和临时值的安全位置操作。
因此像 Hotspot 这种现代 JVMs 实现了协作机制：线程经常询问是否应该将控制权交给 VM，在线程生命周期中某些已知的位置，线程的状态是已知的。当所有线程都在已知的位置停止的时候，VM 被认为是到达了安全点。检查安全点请求的代码片段因此被称为安全点检查（safepoint polls）
这种实现需要满足以下有趣的权衡：安全点检查很少触发进程停止，所以在不触发时应该非常高效。我们可以通过实验观测么？
实践
考虑这个简单的 JMH 测试用例：
import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;
@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 EmptyBench {
@Benchmark
public void emptyMethod() {
// This method is intentionally left blank.
}
}
你可能认为这个测试用例测量的是空方法，但是实际上这测量的是执行测试用例最小的基础设施代码：统计迭代，等待迭代执行时间。这段代码执行的非常快，所以可以使用 -prof perfasm 剖析执行过程。
这是原装 OpenJDK 8u191 的执行结果：
3.60% ...a2: movzbl 0x94(%r8),%r10d ; load "isDone" field
0.63% │ ...aa: add $0x1,%rbp ; iterations++;
32.82% │ ...ae: test %eax,0x1765654c(%rip) ; global safepoint poll
58.14% │ ...b4: test %r10d,%r10d ; if !isDone, do the cycle again
╰ ...b7: je ...a2
这个空方法被内联了，所有的调用成本都消除了，仅仅剩下基础设施逻辑。
看到 “global safepoint poll” 了么？当需要检查点的时候，JVM 将会持有“检查页（polling page）”[1]，任何对该页的读操作将会触发 段错误 (SEGV)。当安全点检查最终触发 SEGV 时，控制权将会传递给任一存在的 SEGV 处理器，JVM 已经准备好了一个！可以看一下 JVM_handle_linux_signal 如何处理段错误。
所有这些技巧的目的是使得安全点的成本尽可能低，因为很多位置都需要安全点，但是几乎不会触发。基于这个原因，使用 test %eax, (addr) 指令：当安全点检查没有触发的时候，这条指令没有作用[2]。这条指令的编码也很紧凑，在 x86_64 平台仅仅占用6字节。对于给定 JVM 进程，检查的页地址是固定的，所以 JIT 生成的代码可以使用相对 RIP 寻址（RIP-relative addressing）：从当前指令指针给定页地址的偏移量，而不需要耗费空间编码8字节绝对地址。
通常来说只有一个检查页来处理所有线程，所以生成的代码不需要辨别当前执行的线程。但是如果 VM 想要停止单个线程，如何操作？JEP-312: "Thread-Local Handshakes" 给出了这个问题的答案。为 VM 提供了对单个线程触发握手（handshake）检查的能力，当前是通过为每个线程分配单独的检查页实现的，检查指令读取线程局部存储（thread-local storage）中的页地址。[3][4]
这是原装 OpenJDK 11.0.1 的执行结果：
0.31% ...70: movzbl 0x94(%r9),%r10d ; load "isDone" field
0.19% │ ...78: mov 0x108(%r15),%r11 ; reading the thread-local poll page addr
25.62% │ ...7f: add $0x1,%rbp ; iterations++;
35.10% │ ...83: test %eax,(%r11) ; thread-local handshake poll
34.91% │ ...86: test %r10d,%r10d ; if !isDone, do the cycle again
╰ ...89: je ...70
这纯粹是运行时的问题，所以可以通过 -XX:-ThreadLocalHandshakes 关闭这个特性，生成的代码将会与 8u191 中的一样。这解释了 8 与 11 测试结果不同的原因（让我们马上用 -prof perfnorm 执行测试用例）：
Benchmark Mode Cnt Score Error Units
# 8u191
EmptyBench.test avgt 15 0.383 ± 0.007 ns/op
EmptyBench.test:CPI avgt 3 0.203 ± 0.014 #/op
EmptyBench.test:L1-dcache-load-misses avgt 3 ≈ 10⁻⁴ #/op
EmptyBench.test:L1-dcache-loads avgt 3 2.009 ± 0.291 #/op
EmptyBench.test:cycles avgt 3 1.021 ± 0.193 #/op
EmptyBench.test:instructions avgt 3 5.024 ± 0.229 #/op
# 11.0.1
EmptyBench.test avgt 15 0.590 ± 0.023 ns/op ; +0.2 ns
EmptyBench.test:CPI avgt 3 0.260 ± 0.173 #/op
EmptyBench.test:L1-dcache-loads avgt 3 3.015 ± 0.120 #/op ; +1 load
EmptyBench.test:L1-dcache-load-misses avgt 3 ≈ 10⁻⁴ #/op
EmptyBench.test:cycles avgt 3 1.570 ± 0.248 #/op ; +0.5 cycles
EmptyBench.test:instructions avgt 3 6.032 ± 0.197 #/op ; +1 instruction
# 11.0.1, -XX:-ThreadLocalHandshakes
EmptyBench.test avgt 15 0.385 ± 0.007 ns/op
EmptyBench.test:CPI avgt 3 0.205 ± 0.027 #/op
EmptyBench.test:L1-dcache-loads avgt 3 2.012 ± 0.122 #/op
EmptyBench.test:L1-dcache-load-misses avgt 3 ≈ 10⁻⁴ #/op
EmptyBench.test:cycles avgt 3 1.030 ± 0.079 #/op
EmptyBench.test:instructions avgt 3 5.031 ± 0.299 #/op
所以线程局部握手增加了一次额外的 L1 命中加载，这耗费了大约半个周期。这也为我们评估安全点检查的成本提供了一些基准：L1 命中加载，大概额外耗费半个周期。
观察
安全点和握手检查是托管运行时系统实现中的小细节。它们经常出现在生成代码的热路径中，有时候会影响性能，特别是在密集的循环中。然而，对于运行时系统实现诸如垃圾回收、锁优化、逆优化等重要的特性，这些操作是必要的。
有许多安全点相关的优化，我们将会单独讨论。
- 在 Linux/POSIX 中，调用
mprotect(PROT_NONE)就足够了。 - 差不多吧。在 x86 中，这条指令改变标志位，但是下一条指令将会重写，我们只需要注意别在
test和相关的jCC之间再做安全点检查。 - 线程局部存储是每个线程可以访问的一段本地数据。在许多平台中，寄存器的压力不是很高，生成的代码总是将线程局部存储放在寄存器中。在 x86_64 中，存储位置通常是
%r15。 - 从技术上讲，停止一部分线程不是一个“安全点”。但是当线程局部握手（thread-local handshakes）启动的时候，可以通过握手所有线程实现安全点。对于“安全点”和“握手”的场景都支持。
