PHP 8的Just In Time是Opcache扩展的一部分，旨在在运行时将某些操作码编译为CPU指令。这意味着使用JIT时，Zend VM不需要解释某些操作码，而这些指令将直接作为CPU级指令执行。

PHP 8 JIT

PHP 8将带来的最受好评的功能之一是Just In Time(JIT)编译器。许多博客和社区都在谈论它，并且肯定会引起很大的轰动，但是到目前为止，我发现关于JIT内部的细节很少。

经过多次研究和放弃后，我决定亲自检查PHP源代码。结合我对C语言的一点了解以及到目前为止所收集的所有分散信息，我提出了这篇文章，希望它也能帮助您更好地了解PHP的JIT。

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

这就是JIT核心思想。

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

PHP代码如何执行？

我们都知道php是一种解释语言。但这到底是什么意思？

每当您要执行PHP代码(例如代码段或整个Web应用程序)时，都必须经过php解释器。

最常用的是PHP FPM和CLI解释器。

他们的工作非常简单：接收php代码，对其进行解释并向后吐出结果。

这通常发生在每种解释语言上。有些语言可能会删除一些步骤，但总体思路是相同的。

在PHP中，它是这样的：

PHP代码被读取并转换为一组关键字，即标记(Tokens)。这个过程允许解释器理解在程序的哪一部分中写了哪段代码。这第一步叫做词法分析或符号化。

有了Tokens后，PHP解释器将分析这个Tokens集合，并尝试理解它们。结果通过一个称为解析的过程生成了一个抽象语法树(AST)。这个AST是一组指示应该执行哪些操作的节点。例如，“echo 1 + 1”实际上应该表示“打印1 + 1的结果”，或者更实际一些“打印一个操作，操作是1 + 1”。

3 . 有了AST，理解操作和优先级就容易得多了。将这个树转换成可以执行的东西需要一个中间表示(IR)，在PHP中我们称之为操作码。将AST转换为操作码的过程称为编译。

现在，有了操作码，剩下就是执行代码。PHP有一个名为Zend VM的引擎，它能够接收操作码列表并执行它们。在执行了所有操作码之后，Zend VM就存在了，程序就终止了。

执行的过程使用下图标识就更加清楚了。

非常直接，正如你们所能理解的。但这里有一个瓶颈:如果php代码变化不是那么频繁，那么每次执行代码时对其进行词法分析又有什么意义呢?

最后我们只关心操作码，对吧? 没错! 这就是为什么存在Opcache扩展。

Opcache扩展

Opcache扩展是随PHP附带的，通常没有什么理由禁用它。如果使用PHP，应该打开Opcache。

它的作用是为操作码在内存中添加一个共享缓存层。它的工作是从AST中新生成的操作码并缓存它们，以便进一步执行可以轻松跳过词法分析和解析阶段。

Opcache扩展的流程示意图：

PHP使用Opcache的解释流程。如果文件已经被解析，则php会为其获取缓存的操作码，而不是再次解析。

opcache完美地跳过了词法分析，语法解析和编译步骤。

注意：这就是PHP 7.4的预加载功能的亮点！它使您可以告诉PHP FPM解析代码库，将其转换为操作码并甚至在执行任何操作之前就对其进行缓存。

JIT即时编译器有效地做什么？

如果Opcache可以更快地获取操作码，这样它们就可以直接转到Zend VM，那么JIT应该让它们在跳过Zend VM的情况下运行。

Zend VM是一个用C编写的程序，充当操作码和CPU本身之间的一个层。JIT所做的是在运行时生成编译后的代码，这样php就可以跳过Zend VM直接转到CPU。理论上讲，我们应该从中获得性能提升。

起初，这对我来说很奇怪，因为为了编译机器代码，您需要为每种类型的体系结构编写一个非常具体的实现。但事实上，它是相当合理的。

PHP的JIT实现使用名为DynASM (Dynamic Assembler)的库，该库将一组特定格式的CPU指令映射为许多不同CPU类型的汇编代码。因此，Just In Time编译器使用DynASM将操作码转换为特定于架构的机器码。

不过，有一个想法困扰了我很长一段时间……

如果预加载能够在执行前将php代码解析为操作码，而DynASM可以将操作码编译为机器码(正好是及时编译)，那么为什么我们不使用提前编译的方法直接编译php呢?!

我从收听Zeev的那集中得到的一个线索是PHP是弱类型的，这意味着PHP通常不知道变量的类型，直到Zend VM尝试执行某个操作码。

这可以通过查看zend_value联合类型看出，它有许多指针指向一个变量的不同类型表示。无论何时Zend VM尝试从zend_value中获取值，它都会使用像ZSTR_VAL这样的宏来尝试从值联合中访问字符串指针。

例如，这个Zend VM处理程序应该处理一个“小于或等于”(<=)表达式。看看它是如何分支到许多不同的代码路径的，只是为了猜测操作数类型。

用机器码复制这种类型推断逻辑是不可行的，可能会使事情变得更慢。

在计算类型之后编译所有内容也不是一个好选择，因为编译成机器码是一项CPU密集型任务。所以在运行时编译所有东西也是不好的。

JIT即时编译器是如何工作的？

现在我们知道我们不能在编译前推断出足够好的类型。我们还知道，在运行时进行编译是昂贵的。JIT对PHP有什么好处?

为了平衡这个等式，PHP的JIT只尝试编译一些它认为可以得到回报的操作码。为此，它对Zend VM正在执行的操作码进行概要分析，并检查哪些操作码可以编译。(根据您的配置)

当编译某个操作码时，它将把执行委托给编译后的代码，而不是委托给Zend VM。看起来如下:

PHP的JIT解释流程。如果已编译，则操作码不会通过Zend VM执行。

所以在Opcache扩展中有一些指令检测某个操作码是否应该编译。如果是，编译器然后使用DynASM将该操作码转换为机器码，并执行新生成的机器码。

有趣的是，由于当前实现中编译的代码有兆字节限制(也是可配置的)，因此代码执行必须能够在JIT和解释代码之间无缝切换。

我仍然不确定编译部分什么时候有效地发生，但我想我现在真的不想知道。

因此性能的提高可能不会很大

为什么每个人都说大多数php应用程序不会从使用Just In Time编译器中获得很大的性能好处，我希望现在能够清楚地知道这一点。以及为什么Zeev建议对应用程序进行分析并试验不同的JIT配置是最好的方法。

如果您使用的是PHP FPM，编译后的操作码通常会在多个请求之间共享，但这仍然不能改变游戏规则。

这是因为JIT优化了cpu绑定操作，而现在大多数php应用程序都是I/O绑定的。如果你必须访问磁盘或网络，不管处理操作是否被编译。计时也非常类似。

文章翻译自https://thephp.website/en/issue/php-8-jit/

5.0

02

Post Views:

942