理解 PHP 8 的 JIT

 

 

TL;DR

PHP 8 的 JIT（Just In Time）编译器将做为扩展集成到 php 中 Opcache 扩展 用于运行时将某些操做码直接转换为从 cpu 指令。

这意味着使用 JIT 后，Zend VM 不须要解释某些操做码，而且这些指令将直接做为 CPU 级指令执行。

PHP 8 的 JIT

PHP 8 Just In Time (JIT) 编译器带来的影响是毋庸置疑的。可是到目前为止，我发现关于 JIT 应该作什么却知之甚少。

通过屡次研究和放弃，我决定亲自检查 PHP 源代码。结合我对 C 语言的一些知识和我目前收集到的全部零散信息，我提出了这篇文章，我但愿它能帮助您更好地理解 PHP 的 JIT。

简单一点来讲 ： 当 JIT 按预期工做时，您的代码不会经过 Zend VM 执行，而是做为一组 CPU 级指令直接执行。

这就是所有的想法。

可是为了更好地理解它，咱们须要考虑 php 如何在内部工做。不是很复杂，但须要一些介绍。

PHP 的代码是怎么执行的？

总所周知， PHP 是解释型语言，但这句话自己是什么意思呢？

每次执行 PHP 代码（命令行脚本或者 WEB 应用）时，都要通过 PHP 解释器。最经常使用的是 PHP-FPM 和 CLI 解释器。

 

解释器的工做很简单：接收 PHP 代码，对其进行解释，而后返回结果。

通常的解释型语言都是这个流程。有些语言可能会减小几个步骤，但整体的思路相同。在 PHP 中，这个流程以下：

1. 读取 PHP 代码并将其解释为一组称为 Tokens 的关键字。这个过程让解释器知道各个程序都写了哪些代码。 这一步称为 Lexing 或 Tokenizing 。
2. 拿到 Tokens 集合之后，PHP 解释器将尝试解析他们。经过称之为 Parsing 的过程生成抽象语法树（AST）。这里 AST 是一个节点集表示要执行哪些操做。好比，「 echo 1 + 1 」实际含义是 「打印 1 + 1 的结果」 或者更详细的说 「打印一个操做，这个操做是 1 + 1」。
3. 有了 AST ，能够更轻松地理解操做和优先级。将抽象语法树转换成能够被 CPU 执行的操做须要一个用于过渡的表达式 (IR)，在 PHP 中咱们称之为 Opcodes 。将 AST 转换为 Opcodes 的过程称为 compilation 。
4. 有了 Opcodes ，有趣的部分就来了： executing 代码！ PHP 有一个称为 Zend VM 的引擎，该引擎可以接收一系列 Opcodes 并执行它们。执行全部 Opcodes 后， Zend VM 就会将该程序终止。

这个图可让你更清楚：

 

一个简化版的 PHP 解释流程概述。

如你所见。这里有个问题：即便 PHP 代码没改变，每次执行仍是会走此流程吗？

让咱们看回 Opcodes 。对了！这就是 Opcache 扩展 存在的缘由。

 

Opcache 扩展

Opcache 扩展是 PHP 附带的，一般不必停用它。使用 PHP 最好打开 Opcache 。

 

它的做用是为 Opcodes 添加一个内存共享缓存层。它的工做是从 AST 中提取新生成的 Opcodes 并缓存它们，以便执行时

能够跳过 Lexing/Tokenizing 和 Parsing 步骤。

这是包含 Opcache 扩展的流程示意图：

 

 

PHP 使用 Opcache 的解释流程。若是文件已经被解析，则 PHP 会为其获取缓存的 Opcodes ，而不是再次解析。

 

完美的跳过了 Lexing/Tokenizing 、 Parsing 和 Compiling 步骤 。

 

旁注： 这是超赞的 PHP 7.4 预加载功能 RFC ! 容许你告诉 PHP FPM 解析代码库，将其转换为 Opcodes 而且在执行以前就将其缓存。

你想知道 JIT 是怎么参与这个解释流程的吗？这篇文章的将说明。

 

Just In Time 编译有什么效果？

听了 Zeev 在 PHP Internals News 发表的 PHP 和 JIT 广播 以后，我弄清了 JIT 实际作了什么事情。

若是说 Opcache 扩展能够更快的获取 Opcodes 将其直接转到 Zend VM，则 JIT 让它们彻底不使用 Zend VM 便可运行。

 

Zend VM 是用 C 编写的程序，充当 Opcodes 和 CPU 之间的一层。 JIT 在运行时直接生成编译后的代码，所以 PHP 能够

 

跳过 Zend VM 并直接被 CPU 执行。 从理论上说，性能会更好。

这听起来很奇怪，由于在编译成机器码以前，须要为每种类型的结构体编写一个具体的实现。但实际上这也是合理的。

PHP 的 JIT 使用了名为 DynASM (Dynamic Assembler) 的库，该库将一种特定格式的一组 CPU 指令映射为许多不一样 CPU 类型的汇编代码。所以，编译器只须要使用 DynASM 就能够将 Opcodes 转换为特定结构体的机器码。

可是，有一个问题困扰了我好久。

若是预加载可以在执行以前将 PHP 代码解析为 Opcodes，而且 DynASM 能够将 Opcodes 编译为机器码 (Just In Time 编译) ，为何咱们不当即使用运行前编译 (Ahead of Time 编译) 当即编译 PHP 呢？

经过收听 Zeev 的广播，我找到的缘由之一就是 PHP 是弱类型语言，这意味着在 Zend VM 尝试执行某个操做码以前， PHP 一般不知道变量的类型。

能够查看 Zend_value 联合类型 得知，不少指针指向不一样类型的变量。每当 Zend VM 尝试从 Zend_value 获取值时，它都会使用像 ZSTR_VAL 这样的宏，获取联合类型中字符串的指针。

例如，这个 Zend VM handler 是处理「小于或等于」(<=) 表达式。看看它编码这么多的 if else 分支，只是为了类型推断。

使用机器码执行类型推断逻辑是不可行的，而且可能变得更慢。

先求值再编译也不是一个好选择，由于编译为机器码是 CPU 密集型任务。所以，在运行时编译全部内容也很差。

那么 Just In Time 编译是怎么作的？

如今咱们知道没法很好的推断类型来提早编译。咱们也知道在运行时进行编译的运算成本很高。那么 JIT 对 PHP 有何好处呢？

 

为了寻求平衡， PHP 的 JIT 尝试只编译有价值的 Opcodes 。为此， JIT 会分析 Zend VM 要执行的 Opcodes 并检查可能编译的地方。（根据配置文件）

当某个 Opcode 编译后，它将把执行交给该编译后的代码，而不是交给 Zend VM 。看起来以下：

 

PHP 的 JIT 解释流程。若是已编译，则 Opcodes 不会经过 Zend VM 执行。

 

所以，在 Opcache 扩展中，有两条检测指令判断要不要编译 Opcode 。若是要，编译器将使用 DynASM 将此 Opcode 转换为机器码，并执行此机器码。

有趣的是，因为当前接口中编译的代码有 MB 的限制 (也是可配置的)，因此代码执行必须可以在 JIT 和解释代码之间无缝切换。

顺便说一句，Benoit Jacquemont 在 php 的 JIT 上的这篇演讲帮助我理解了这整件事。

我仍然不肯定编译部分何时有效进行，但我想如今我真的不想知道。

因此你的性能收益可能不会很大

我但愿如今你们都很清楚为何大多数 php 应用程序不会由于使用即时编译器而得到很大的性能收益。这也是为何 Zeev 建议为你的应用程序分析和试验不一样的 JIT 配置是最好的方法。

若是您使用的是 PHP FPM，则一般会在多个请求之间共享已编译的操做码，但这仍然不能改变游戏规则。

这是由于 JIT 优化了计算密集型的操做，而现在大多数 php 应用程序比其余任何东西都更受 I/O 约束。若是您不管如何都要访问磁盘或网络，则处理操做是否已编译则可有可无。时间上将很是类似。

除非…

你正在作一些不受 I/O 约束的事情， 像图像处理或机器学习。 任何不接触 I/O 的东西都将受益于 JIT 编译器。

这也是为何如今人们说咱们更愿意用 PHP 编写原生功能而不是 C 编写的缘由。 若是仍然要编译此功能，则开销将毫无表现力。

 

有趣的时光成为一个 PHP 程序员…

---

但愿本文对您有所帮助，使您能更好的理解 PHP8 的 JIT。

 

更多PHP内容请访问：

腾讯T3-T4标准精品PHP架构师教程目录大全，只要你看完保证薪资上升一个台阶（持续更新）​