发布于 由admin

PHP JIT 编译器底层实现：分析 Tracing JIT 与 Function JIT 在 CPU 指令集层的物理差异

嘿，各位编程界的“卷王”们，大家好！

欢迎来到今天的底层黑客沙龙。我是你们的老朋友，那个发誓再也不写 echo "Hello World" 但最后还是写了五千遍的资深极客。

今天我们不聊什么框架、不聊什么 ORM，也不聊那些花里胡哨的 PSR-7 规范。我们要深入 CPU 的肚子里，去看看当你们那蹩脚的 PHP 代码（比如 foreach 循环跑十万次）变成狂奔的机器码时，究竟发生了什么。

你们可能听说过 JIT (Just-In-Time) 编译器。是的，就是那个让 PHP 从“恐龙”变成“猎豹”的黑科技。但在 PHP 的世界（特别是 PHP 8.0 之后），我们有两个主要派系：Function JIT 和 Tracing JIT。

这就好比一个公司里有两个部门：一个是标准化作业流程 (SOP) 部门，一个是特种行动小组。

今天，我们就穿上防静电服，戴上放大镜，去剖析这两者在 CPU 指令集层面的物理差异。准备好了吗？让我们开始这场硬核解剖。

第一部分：Function JIT —— 按部就班的“正规军”

首先，我们来聊聊 Function JIT。这是 PHP 8 之前时代的“老大哥”，后来也被 8.0 的 Tracing JIT 吸收并改造。

Function JIT 的核心理念很简单：别瞎猜，按规矩出牌。

当一个函数被调用时，就像你走进一家餐厅点菜。Function JIT 会把整个函数从头到尾编译成一个独立的代码块。它不会管你调用它一百次还是一万次，它只负责把这个函数变成一个“标准产品”。

1. 栈帧：Function JIT 的“临时工宿舍”

在 CPU 的世界里，函数调用是非常昂贵的。为什么？因为要维护环境。

当你调用一个函数，CPU 需要保存调用者的状态（比如 EBP 寄存器，或者现在的 RBP）。Function JIT 编译器会生成一系列指令，叫做 Prologue (函数序言)。

让我们看一个极其简单的 PHP 函数：

function add($a, $b) {
    return $a + $b;
}

在 Function JIT 模式下，编译器生成的 x86_64 机器码大概是这样的（简化版）：

; 函数入口：栈帧初始化
push    rbp             ; 把旧的栈底指针压栈，保存上一个函数的环境
mov     rbp, rsp        ; 设置当前的 RBP 指向当前的栈顶（现在的栈底）

; 参数传递 (x86_64 System V ABI)
; $a 在 RDI 寄存器，$b 在 RSI 寄存器（这是 Linux 下函数传参的标准规则）
; 注意：PHP 的变量是“值”，但在底层都是指针 (Zval)，所以这里需要解引用

; 1. 加载参数的值
mov     rax, [rdi]      ; 把 $a 的值从内存（Zval 指向的位置）加载到 RAX 寄存器
add     rax, [rsi]      ; 把 $b 的值加到 RAX 上

; 返回
mov     [rbp-8], rax    ; 把结果存回栈上的临时位置（虽然这里其实可以直接用 RAX 返回，但为了演示栈帧）
mov     eax, [rbp-8]    ; 拿回来

; 函数结尾：恢复现场
leave               ; 相当于 pop rbp; mov rsp, rbp
ret                 ; 弹出返回地址并跳转

物理层面的吐槽：
看懂了吗？每调用一次 add，CPU 就要做一次 push 和 mov。这就好比你每次去打印一张文件，打印机都要重新把滚筒复位一次。虽然快，但如果你只是打印几百张纸，这就不划算了。

而且，Function JIT 是保守的。它不知道 $a 以后永远是整数。所以它必须每次都检查：[rdi] 这个地址存的是不是个整数？如果是字符串怎么办？如果是对象怎么办？

这种类型检查（Type Check）在 CPU 指令层表现为大量的 cmp (比较) 和 jnz (如果不为零跳转)。这就导致了 CPU 的 Branch Prediction（分支预测） 单元忙得不可开交。预测错了？那是惩罚极大的流水线冲刷。

总结一下 Function JIT 的物理特征：

  • 独立性： 每个函数都是一个独立的代码岛屿。
  • 栈帧： 必须有 prologue 和 epilogue 来管理局部变量。
  • 保守性： 每次执行都像是在走迷宫，到处都是“检查门卫”的指令。
  • 寄存器压力： 也就是 Register Pressure，因为要存栈帧，留给计算的高频寄存器（如 RAX, RBX）就少了。

第二部分：Tracing JIT —— 疯狂追风的“跟踪狂”

现在，让我们把目光转向 Tracing JIT。这是 PHP 8 的当家花旦，它不像 Function JIT 那么规矩，它更像是一个跟踪狂侦探。

1. 追踪：从解释执行到“单一路径”

当你第一次运行 PHP 脚本时，它是解释器 在跑。它逐行读代码。

突然，你运行了一段热代码（比如 while 循环跑了 10,000,000 次）。

Tracing JIT 的眼睛就像雷达一样：“停！这家伙每次都走这一条路！”

于是，解释器开始Trace（追踪）。它看着你的 PHP 代码一行行执行，把它变成一条长长的链条。

它发现：

  1. $a 第一次是 5，第二次是 5，第三次还是 5…
  2. $b 永远是 10。
  3. 这里面没有 switch，没有 instanceof，全是简单的加减乘除。
  4. 调用了 add，但 add 里全是 int 运算。

这时候，Tracing JIT 偷偷溜到后台，开始编译一条特制的“热路径”代码。

2. 汇编层面的“独狼”行为

编译器把 add 函数内部的逻辑，连同调用它的循环，全部展开，编译成了一个没有栈帧的巨大循环体。

来看看这个巨大的代码块（这是 Tracing JIT 优化后的物理状态）：

; 假设我们追踪到了一个循环：for ($i=0; $i<1000000; $i++) { $sum += $i; }
; 此时 Tracing JIT 知道 $sum 一直都是整数

.loop_start:
    ; 直接从内存加载 $sum 的值到寄存器
    mov     rax, [rsi]        ; [rsi] 是追踪到的“局部变量”内存地址
    add     rax, rcx          ; rcx 是 $i 的值
    mov     [rsi], rax        ; 把结果写回内存

    ; 优化：不需要检查类型！直接加减！
    ; 不需要检查数组越界！因为 Tracing JIT 知道 $sum 不会爆栈！

    ; 循环逻辑
    inc     rcx
    cmp     rcx, 0x0F4240     ; 比较 $i 和 1,000,000 (十六进制)
    jl      .loop_start       ; 如果小于，就跳回开头 (Jump to Loop Start)

    ; 结束追踪
    ; 注意：这里没有 Ret！因为我们在循环里！
    ; 如果是 Function JIT，这里会执行 leave 和 ret。
    ; 但在这里，我们要么死循环，要么跳到 Tracer 的控制点去汇报成果。
    jmp     .loop_start       ; 重新跳回去跑下一圈

物理层面的震撼：
你看这个汇编代码，是不是感觉非常“暴力”且“直接”？

  1. 没有 call 和 ret： Function JIT 调用函数需要 call，这会压栈返回地址。而 Tracing JIT 把函数内联了。原本的 call add 变成了直接的操作。省去了压栈和弹栈的时间。
  2. 没有栈帧： 没有那个 push rbp 和 mov rbp, rsp。寄存器 rbp 空出来了！这意味着 rbp 可以被拿来做计算！这就极大地减少了 Register Spilling (寄存器溢出)——也就是把寄存器里的东西暂时存回内存，下次再用。溢出是性能的噩梦！
  3. 移除检查： Function JIT 需要确认 [rsi] 是不是整数。它生成 test 指令检查标志位。Tracing JIT 呢？它利用内联缓存。它假设这一次是整数，如果是，就一直走这条路；如果不是，它就放弃这条 Trace（把它烧了），然后重新开始追踪。

第三部分：硬碰硬的 CPU 指令层对决

好了，理论说多了有点晕。让我们把这两个家伙拉到擂台上，通过汇编代码的微观视角，看看它们到底有什么本质区别。

1. 边界检查与控制流

Function JIT 的物理图景：
想象你在搭积木。每次搭完一块积木（一个指令），你都要看看周围有没有护栏（边界检查）。
CPU 的流水线看到了：
if ($a > 0) -> cmp rax, 0 -> jg .positive。
如果预测错了，流水线就完了，得清空。这就像开车，每次变道都要看后视镜。

Tracing JIT 的物理图景：
Tracing JIT 就像是一个赛车手，他在一条从未被质疑过的赛道上狂飙。
如果 Tracer 发现了 if ($a > 0) 这条路径跑了 100 万次都没错，它就彻底抹去这个 if。
CPU 看到的就是：add rax, rsi -> jmp .loop。
没有任何分支！CPU 流水线畅快淋漓，预测器对着预测器疯狂点头。这就是所谓的 “Cold Path Warm-up”（冷路径热身）。

2. 数据传递：指针解引用的物理损耗

这是 PHP 最痛的地方。PHP 的变量是一个结构体 zval。

Function JIT 的物理损耗：
每次你写 $a = $a + 1，Function JIT 必须这么做：

  1. mov rax, [rbp-0x10] — 从栈上取到 $a 的地址。
  2. mov rbx, [rax] — 去内存里把指针（Value）拿出来。
  3. add rbx, 1 — 加 1。
  4. mov [rax], rbx — 把结果写回内存。
  5. mov rbx, [rax] — 再取一次（为了传给 return，虽然通常直接用寄存器返回）。

注意第 2 步和第 5 步！这叫 Load/Store (加载/存储)。CPU 的 L1 缓存很快，但还没快到能忽略这些周期。每条指令都伴随着内存延迟。

Tracing JIT 的物理优化：
Tracing JIT 也很穷，但它更聪明。它发现 $a 一直是个整数，而且 $a 在函数执行期间（在这个 Trace 内）从不改变指向（没有改变 $a = &$b 这种引用赋值）。

于是，它做了一个大胆的物理操作：Register Stashing (寄存器暂存)。

; Tracing JIT 做的事
mov     rax, [rsi]        ; 初始加载
.loop:
    add     rax, 1
    mov     [rsi], rax      ; 写回去
    jmp     .loop

等等，这不还是 Load/Store 吗？
是的，但在现代 CPU 上，如果我们把 [rsi] 这个地址一直放在 LD1 指令缓存里，并且保持 rsi 寄存器一直被有效占用（不让别的寄存器抢占），CPU 就能极快地访问它。

更重要的是，如果 Tracing JIT 能优化到把 $a 的值直接死绑在某个通用寄存器里（比如 RAX），它甚至可以完全不去动内存！

mov     rax, 5            ; 假设 $a 初始是 5，且 Tracer 优化掉了内存写回
.loop:
    add     rax, 1          ; 直接在寄存器里加，零内存访问！
    jmp     .loop

虽然这很难，但 Tracing JIT 的目标就是尽可能把计算推给寄存器，拒绝内存访问。

3. 内存对齐与缓存行

Function JIT：
由于函数调用会改变栈指针 rsp，局部变量的位置是动态的。这导致 CPU 缓存行（Cache Line, 通常是 64 字节）很难预取。
想象一下，你读一页书，每次读完一章，书页就变了。CPU 就得不断去内存里找新的书页。这就是 Cache Miss（缓存未命中）。

Tracing JIT：
Tracing JIT 生成的代码块通常很紧凑，局部变量的地址通常是固定的（相对偏移）。这让 CPU 预取器非常高兴：“嘿，我只要把这一块内存提前读进来就行了！”
这就是 Spatial Locality（空间局部性） 的胜利。

第四部分：实战演示——模拟 CPU 的视角

让我们来个夸张的对比。假设你要在 PHP 里做一个 3D 渲染循环（虽然 PHP 不适合做这个，但为了演示）。

场景 A：Function JIT 编译模式

function renderFrame($mesh) {
    $verts = $mesh->getVertices();
    for ($i = 0; $i < count($verts); $i++) {
        $v = $verts[$i];
        $v->x += $v->y * 0.5; // 复杂计算
    }
    return $mesh;
}

CPU 指令流（Function JIT）：

  1. call renderFrame
  2. push rbp
  3. mov rbp, rsp
  4. sub rsp, 0x20
  5. mov rax, [rdi] <– 加载 $mesh
  6. mov rcx, [rax] <– 加载 $verts 数组指针
  7. mov rdx, [rcx] <– 加载数组大小 (count)
  8. cmp rdx, 0 <– 检查数组边界 (这是 Function JIT 的恶梦)
  9. jl .exit <– 边界检查失败跳转
  10. mov r8, [rbp-0x8] <– 加载 $i
  11. mov r9, [rcx+r8*8] <– 数组取值 ($verts[$i])
  12. movsd xmm0, [r9] <– 加载向量 X
  13. ... 复杂的 FPU 指令 ...
  14. movsd [r9], xmm0 <– 写回向量 X
  15. inc r8
  16. mov [rbp-0x8], r8 <– 写回 $i
  17. jmp 9 (回到检查)

评价： 每次循环都要 sub rsp（分配栈空间），都要检查数组边界，都要访问内存。CPU 老爷子都累得满头大汗，看着预测器乱跳。

场景 B：Tracing JIT 编译模式

假设这个函数被调用了 1 亿次，且每次都是同一个 $mesh，且数组大小不变。

CPU 指令流（Tracing JIT）：

  1. mov rcx, [rdi] <– 缓存 $mesh 和 $verts
  2. mov rdx, [rcx] <– 缓存数组长度 (常量)
  3. mov rax, 0 <– 初始化 $i
  4. cmp rax, rdx <– 比较边界
  5. jge .end_trace <– 越界就断开追踪
  6. mov r8, [rcx+rax*8] <– 直接数组取值
  7. movsd xmm0, [r8] <– 加载数据
  8. addsd xmm0, [r8+8] <– 计算 (假设 y 在 x 后面)
  9. mulsd xmm0, [rip+0x123456] <– 乘 0.5
  10. movsd [r8], xmm0 <– 写回
  11. inc rax
  12. jmp 4 (回到比较)

评价：
看到了吗？没有 push/pop，没有栈帧。所有的变量都在通用寄存器里（rax, rcx, rdx, r8）。除了边界检查还在（没办法，这是数组操作），其他的操作都在寄存器之间疯狂跳转。
指令数减少了 30% 以上。 这就是物理速度的提升。

第五部分：为什么 Function JIT 没死透？（遗留系统的尊严）

你可能会问：“既然 Tracing JIT 这么强，为什么 PHP 还要保留 Function JIT 的代码？”

因为 Tracing JIT 有个致命缺陷：它只认‘老熟人’。

Tracing JIT 是个势利眼。如果你第一次调用函数就传了个字符串，Tracer 就会放弃这条路径，编译器就会觉得：“哎呀，这条路太复杂，全是随机性，算了吧。”
然后下一次你传整数，它又要重新 Trace。

这就是 “Trace Warm-up”（追踪预热） 问题。前几百万次调用可能还是很慢，因为 JIT 还在适应你的数据模式。

而 Function JIT 是个绅士。它不管你第一次传什么，它都给你生成一份标准代码。虽然它每次都要做检查，但它稳。
对于那些不那么热（不常跑）的函数，Function JIT 依然是主力。而且 Function JIT 可以独立优化，比如内联某些简单的辅助函数。

所以，现代 PHP 的 JIT 策略是混合的：“用 Function JIT 处理冷代码，用 Tracing JIT 洗劫热代码。”

结语：物理学的胜利

回到我们的讲座主题。

Function JIT 在物理层面上，就像是搭乐高。它把每一块积木（指令）都排列整齐，遵守严格的建筑规范（调用约定），即使这意味着每次搭完都要擦屁股（清理栈帧）。

Tracing JIT 则像是速滑。它无视那些死板的规则（函数调用边界、类型检查），它只关注那一圈它觉得最顺的路（热路径）。它把多余的装饰（栈帧）全部剪掉，只留下最锋利的刀刃（寄存器运算）。

当你在 CPU 那每秒 3GHz 的频率下运行 PHP 代码时，你看到的不只是一行行代码，而是成千上万个物理指令在寄存器之间的高速舞蹈。

Function JIT 是结构的胜利，Tracing JIT 是数据的胜利。

这就是为什么，当你用 PHP 8 写一个高负载的循环时，你会感觉代码仿佛化为了流体，直接流淌进了硬件的深处。

好了，今天的讲座就到这里。记得，下次写代码的时候，想想你的 CPU 正在为了你的变量类型检查而流汗。如果可能的话，尽量让它偷懒——这就是 Tracing JIT 的哲学，也是高性能编程的哲学。

谢谢大家！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注