原文地址：JVM Anatomy Park #20: FPU Spills
问题
当代码中完全没有浮点数或者向量操作的时候，我在 JVM 生成的 x86 机器码中居然也看到了 XMM 寄存器的使用。这是怎么回事？
理论
浮点运算单元（FPU）和向量单元（vector unit）普遍存在于现代 CPU 中，在许多情况下它们为 FPU 特定操作提供了寄存器。例如 Intel x86_64 中的 SSE 和 AVX 增设了 XMM、YMM 和 ZMM 寄存器，这些寄存器可以用于配合更宽的指令。
虽然非向量指令集并不与向量和非向量寄存器正交（例如，在 x86_64 中我们不能在 XMM 寄存器上使用通用的 IMUL），但是这些寄存器仍然提供了一个有趣的存储功能：我们可以在其中临时存储数据，即使这些数据不用于向量操作。[1]
关于寄存器分配。寄存器分配器的职责是，维护在特定的编译单元（例如，方法）中程序需要的所有操作数的程序表示，并且映射这些虚操作数到实际的机器寄存器 —— 为它们分配寄存器。在许多真实的程序中，在给定程序位置，虚操作数的数量会大于可用机器寄存器的数量。在那时，寄存器分配器需要将某些操作数放到寄存器之外的其它位置 —— 比如放到栈上 —— 也就是，溢出操作数。
现在在 x86_64 中有 16 个通用寄存器（并不是所有的都可用），在大部分现代的机器上还会有 16 个 AVX 寄存器。我们可以溢出到 XMM 寄存器，而不是栈上么？是的，我们可以！这有什么好处么？
实践
考虑这个简单的 JMH 测试用例。我们用一种特别的方式构建测试用例（假设 Java 具有预处理能力，为简单起见）：
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 FPUSpills {
int s00, s01, s02, s03, s04, s05, s06, s07, s08, s09;
int s10, s11, s12, s13, s14, s15, s16, s17, s18, s19;
int s20, s21, s22, s23, s24;
int d00, d01, d02, d03, d04, d05, d06, d07, d08, d09;
int d10, d11, d12, d13, d14, d15, d16, d17, d18, d19;
int d20, d21, d22, d23, d24;
int sg;
volatile int vsg;
int dg;
@Benchmark
#ifdef ORDERED
public void ordered() {
#else
public void unordered() {
#endif
int v00 = s00; int v01 = s01; int v02 = s02; int v03 = s03; int v04 = s04;
int v05 = s05; int v06 = s06; int v07 = s07; int v08 = s08; int v09 = s09;
int v10 = s10; int v11 = s11; int v12 = s12; int v13 = s13; int v14 = s14;
int v15 = s15; int v16 = s16; int v17 = s17; int v18 = s18; int v19 = s19;
int v20 = s20; int v21 = s21; int v22 = s22; int v23 = s23; int v24 = s24;
#ifdef ORDERED
dg = vsg; // Confuse optimizer a little
#else
dg = sg; // Just a plain store...
#endif
d00 = v00; d01 = v01; d02 = v02; d03 = v03; d04 = v04;
d05 = v05; d06 = v06; d07 = v07; d08 = v08; d09 = v09;
d10 = v10; d11 = v11; d12 = v12; d13 = v13; d14 = v14;
d15 = v15; d16 = v16; d17 = v17; d18 = v18; d19 = v19;
d20 = v20; d21 = v21; d22 = v22; d23 = v23; d24 = v24;
}
}
测试用例一次性读写多对字段。优化器实际上不受特定程序顺序的约束。的确，这就是我们在 unordered 测试中观察到的：
Benchmark Mode Cnt Score Error Units
FPUSpills.unordered avgt 15 6.961 ± 0.002 ns/op
FPUSpills.unordered:CPI avgt 3 0.458 ± 0.024 #/op
FPUSpills.unordered:L1-dcache-loads avgt 3 28.057 ± 0.730 #/op
FPUSpills.unordered:L1-dcache-stores avgt 3 26.082 ± 1.235 #/op
FPUSpills.unordered:cycles avgt 3 26.165 ± 1.575 #/op
FPUSpills.unordered:instructions avgt 3 57.099 ± 0.971 #/op
大约有 26 个 load-store 指令对，大致对应测试用例中的 25 对读写操作。但是我们没有 25 个通用寄存器！perfasm 的输出表明，优化器合并了邻近的 load-store 指令对，所以寄存器的压力很低：
0.38% 0.28% movzbl 0x94(%rcx),%r9d
│ ...
0.25% 0.20% │ mov 0xc(%r11),%r10d ; getfield s00
0.04% 0.02% │ mov %r10d,0x70(%r8) ; putfield d00
│ ...
│ ... (transfer repeats for multiple vars) ...
│ ...
╰ je BACK
此时此刻，我们想要欺骗一下优化器，制造一点儿混淆，使得所有的加载操作在存储操作前执行完。这是 ordered 测试的场景，我们可以看到加载和存储操作是分开执行的：首先执行所有加载操作，然后执行所有存储操作。当所有加载操作完成时，寄存器的压力最高，但是此时存储操作还没有开始。即使那样，相对于 unordered 也没有明显的性能区别：
Benchmark Mode Cnt Score Error Units
FPUSpills.unordered avgt 15 6.961 ± 0.002 ns/op
FPUSpills.unordered:CPI avgt 3 0.458 ± 0.024 #/op
FPUSpills.unordered:L1-dcache-loads avgt 3 28.057 ± 0.730 #/op
FPUSpills.unordered:L1-dcache-stores avgt 3 26.082 ± 1.235 #/op
FPUSpills.unordered:cycles avgt 3 26.165 ± 1.575 #/op
FPUSpills.unordered:instructions avgt 3 57.099 ± 0.971 #/op
FPUSpills.ordered avgt 15 7.961 ± 0.008 ns/op
FPUSpills.ordered:CPI avgt 3 0.329 ± 0.026 #/op
FPUSpills.ordered:L1-dcache-loads avgt 3 29.070 ± 1.361 #/op
FPUSpills.ordered:L1-dcache-stores avgt 3 26.131 ± 2.243 #/op
FPUSpills.ordered:cycles avgt 3 30.065 ± 0.821 #/op
FPUSpills.ordered:instructions avgt 3 91.449 ± 4.839 #/op
这是因为我们设法将操作数溢出到了 XMM 寄存器，而不是栈上：
3.08% 3.79% vmovq %xmm0,%r11
│ ...
0.25% 0.20% │ mov 0xc(%r11),%r10d ; getfield s00
0.02% │ vmovd %r10d,%xmm4 ; <--- FPU SPILL
0.25% 0.20% │ mov 0x10(%r11),%r10d ; getfield s01
0.02% │ vmovd %r10d,%xmm5 ; <--- FPU SPILL
│ ...
│ ... (more reads and spills to XMM registers) ...
│ ...
0.12% 0.02% │ mov 0x60(%r10),%r13d ; getfield s21
│ ...
│ ... (more reads into registers) ...
│ ...
│ ------- READS ARE FINISHED, WRITES START ------
0.18% 0.16% │ mov %r13d,0xc4(%rdi) ; putfield d21
│ ...
│ ... (more reads from registers and putfileds)
│ ...
2.77% 3.10% │ vmovd %xmm5,%r11d : <--- FPU UNSPILL
0.02% │ mov %r11d,0x78(%rdi) ; putfield d01
2.13% 2.34% │ vmovd %xmm4,%r11d ; <--- FPU UNSPILL
0.02% │ mov %r11d,0x70(%rdi) ; putfield d00
│ ...
│ ... (more unspills and putfields)
│ ...
╰ je BACK
注意，我们对一些操作数使用通用寄存器（GPRs），但是当通用寄存器耗尽时，操作数就会溢出了。这里的“因果关系”定义不明确，因为我们似乎是首先溢出了，然后使用 GPRs，但是这只是错误的表象，因为寄存器分配器可以直接对所有寄存器进行分配。[2]
XMM 溢出的延迟看起来很小：尽管我们为溢出声明了更多指令，但是指令执行非常高效，填补了流水线的缺口：34 个附加的指令，意味着溢出了大约 17 对，但是只增加了 4 个周期。注意，4/34 = ~0.11 clk/insn 这样计算 CPI 是不正确的，这超出了当前 CPU 的能力。但是性能的改善是真实的，因为我们使用了之前没用过的执行指令。
如果没有比较的对象，那么所谓的效率就没有意义了。但是这里，我们有！我们可以用 -XX:-UseFPUForSpilling 使得 Hotspot 避免使用 FPU 溢出，这让我们可以了解使用 XMM 溢出获得了多大收益：
Benchmark Mode Cnt Score Error Units
# Default
FPUSpills.ordered avgt 15 7.961 ± 0.008 ns/op
FPUSpills.ordered:CPI avgt 3 0.329 ± 0.026 #/op
FPUSpills.ordered:L1-dcache-loads avgt 3 29.070 ± 1.361 #/op
FPUSpills.ordered:L1-dcache-stores avgt 3 26.131 ± 2.243 #/op
FPUSpills.ordered:cycles avgt 3 30.065 ± 0.821 #/op
FPUSpills.ordered:instructions avgt 3 91.449 ± 4.839 #/op
# -XX:-UseFPUForSpilling
FPUSpills.ordered avgt 15 10.976 ± 0.003 ns/op
FPUSpills.ordered:CPI avgt 3 0.455 ± 0.053 #/op
FPUSpills.ordered:L1-dcache-loads avgt 3 47.327 ± 5.113 #/op
FPUSpills.ordered:L1-dcache-stores avgt 3 41.078 ± 1.887 #/op
FPUSpills.ordered:cycles avgt 3 41.553 ± 2.641 #/op
FPUSpills.ordered:instructions avgt 3 91.264 ± 7.312 #/op
哎呀，看到每次操作增长的 load/store 计数器了吗？这些就是栈溢出：栈虽然很快，但是也是在内存中呀，因此需要访问 L1 缓存中的栈空间。此时也需要溢出大约 17 对，但是现在增加了 11 个周期。L1 缓存的吞吐量是这里的限制因素。
最后，我们可以看一下 -XX:-UseFPUForSpilling 的 perfasm 输出：
2.45% 1.21% mov 0x70(%rsp),%r11
│ ...
0.50% 0.31% │ mov 0xc(%r11),%r10d ; getfield s00
0.02% │ mov %r10d,0x10(%rsp) ; <--- stack spill!
2.04% 1.29% │ mov 0x10(%r11),%r10d ; getfield s01
│ mov %r10d,0x14(%rsp) ; <--- stack spill!
│ ...
│ ... (more reads and spills to stack) ...
│ ...
0.12% 0.19% │ mov 0x64(%r10),%ebp ; getfield s22
│ ...
│ ... (more reads into registers) ...
│ ...
│ ------- READS ARE FINISHED, WRITES START ------
3.47% 4.45% │ mov %ebp,0xc8(%rdi) ; putfield d22
│ ...
│ ... (more reads from registers and putfields)
│ ...
1.81% 2.68% │ mov 0x14(%rsp),%r10d ; <--- stack unspill
0.29% 0.13% │ mov %r10d,0x78(%rdi) ; putfield d01
2.10% 2.12% │ mov 0x10(%rsp),%r10d ; <--- stack unspill
│ mov %r10d,0x70(%rdi) ; putfield d00
│ ...
│ ... (more unspills and putfields)
│ ...
╰ je BACK
是的，栈溢出的位置与 XMM 溢出的位置类似。
观察
FPU 溢出是缓解寄存器压力的好方法。这不需要增加通用操作的可用寄存器数量，而是为溢出提供了更快的临时存储空间：因此当我们仅仅需要一些额外的溢出槽时，我们可以避免切换到基于 L1 缓存的栈上。
有时这会导致有趣的性能偏差：如果在某些关键路径上没有使用 FPU 溢出，那么我们可能会看到性能下降。例如，慢路径 GC 屏障调用（该调用会清空FPU寄存器）可能会让编译器返回使用基于栈的溢出，而不会尝试高性能的操作。
在 Hotspot 中，-XX:+UseFPUForSpilling 默认支持带有 SSE 的 x86 平台，ARMv7 和 AArch64。所以无论你是否知道这个优化，这对多大部分程序都有效。
[1] 这种技术的极端案例是使用向量寄存器做为行缓冲区！
[2] 某些寄存器分配器可能执行线性分配 —— 提高寄存器分配速度，使生成的代码更高效
