Maglev - V8’s Fastest Optimizing JIT

July 8, 2024

原文：https://v8.dev/blog/maglev
备注：Node.js 22 已默认启用 Maglev 编译器

在Chrome M117中，我们引入了一种新的优化编译器：Maglev。Maglev位于现有的Sparkplug和TurboFan编译器之间，肩负着快速生成足够优秀代码的任务。

背景

直到2021年，V8有两个主要的执行层次：Ignition（解释器）和TurboFan，V8的优化编译器，专注于峰值性能。所有JavaScript代码首先被编译为Ignition字节码，并通过解释执行。在执行过程中，V8会跟踪程序的行为，包括对象形状和类型的跟踪。运行时执行元数据和字节码都被传递给优化编译器，以生成高性能、通常是投机性的机器代码，这些代码的运行速度远快于解释器。

这些改进在JetStream等基准测试中清晰可见，JetStream是一组传统的纯JavaScript基准测试，测量启动、延迟和峰值性能。TurboFan使V8运行该套件的速度提高了4.35倍！JetStream对稳态性能的强调比过去的基准测试（如已退休的Octane基准测试）有所减少，但由于许多项目的简单性，优化后的代码仍然占据了大部分时间。

Speedometer是一种与JetStream不同的基准测试套件。它旨在通过计时模拟用户交互来衡量Web应用的响应能力。与较小的静态独立JavaScript应用不同，该套件由完整的网页组成，其中大多数是使用流行框架构建的。与大多数网页加载期间一样，Speedometer的项目在运行紧密的JavaScript循环上花费的时间要少得多，而更多地执行与浏览器其他部分交互的大量代码。

TurboFan在Speedometer上仍然有很大的影响：它的运行速度提高了超过1.5倍！但其影响显然比在JetStream上要小得多。这部分是因为完整的网页在纯JavaScript上的花费时间较少。但部分原因是基准测试花费了大量时间在没有足够热的函数上，这些函数无法被TurboFan优化。

未优化和优化执行的Web性能基准测试

本文中的所有基准测试分数都是在13英寸M2 Macbook Air上使用Chrome 117.0.5897.3测量的。

由于Ignition和TurboFan之间的执行速度和编译时间差异如此之大，我们在2021年引入了一个新的基线JIT，名为Sparkplug。它旨在几乎瞬间将字节码编译为等效的机器代码。

在JetStream上，与Ignition相比，Sparkplug显著提高了性能（+45%）。即使在有TurboFan的情况下，我们仍然看到性能有了显著提高（+8%）。在Speedometer上，我们看到相对于Ignition的41%的改进，使其接近TurboFan的性能，并且相对于Ignition + TurboFan有22%的改进！由于Sparkplug非常快，我们可以很容易地广泛部署它并获得一致的加速。如果代码不完全依赖于容易优化的长时间运行的紧密JavaScript循环，它是一个很好的补充。

添加了Sparkplug的Web性能基准测试

然而，Sparkplug的简单性对其能提供的加速有一个相对较低的上限。这从Ignition + Sparkplug和Ignition + TurboFan之间的巨大差距中可以清楚地看出。

这就是Maglev的用武之地，我们的新优化JIT，它生成的代码比Sparkplug代码快得多，但生成速度比TurboFan快得多。

Maglev：一个简单的SSA基础JIT编译器

当我们开始这个项目时，我们看到了两条前进的道路，以弥补Sparkplug和TurboFan之间的差距：要么尝试使用Sparkplug的单遍方法生成更好的代码，要么构建一个具有中间表示（IR）的JIT。由于我们认为在编译过程中完全没有IR可能会严重限制编译器，因此我们决定采用一种传统的静态单赋值（SSA）基础的方法，使用CFG（控制流图），而不是TurboFan更灵活但缓存不友好的节点海表示。

编译器本身设计得快速且易于工作。它有一组最小的遍和一个简单的单一IR，编码了专门的JavaScript语义。

预处理

首先，Maglev对字节码进行预处理，以找到分支目标，包括循环和循环中的变量赋值。此遍还收集活动信息，编码哪些变量中的值在哪些表达式中仍然需要。这些信息可以减少编译器稍后需要跟踪的状态量。

SSA

命令行上的Maglev SSA图打印输出

Maglev对帧状态进行抽象解释，创建表示表达式求值结果的SSA节点。变量赋值通过将这些SSA节点存储在相应的抽象解释器寄存器中来模拟。在分支和切换的情况下，所有路径都被评估。

当多个路径合并时，抽象解释器寄存器中的值通过插入所谓的Phi节点来合并：这些值节点知道在运行时根据选择的路径选择哪个值。

循环可以“回到过去”合并变量值，当变量在循环体内被赋值时，数据从循环结束向循环头部反向流动。这就是预处理数据派上用场的地方：由于我们已经知道哪些变量在循环内被赋值，我们可以在开始处理循环体之前预先创建循环Phi。在循环结束时，我们可以用正确的SSA节点填充Phi输入。这使得SSA图生成成为单向遍，而不需要“修复”循环变量，同时最小化需要分配的Phi节点数量。

已知节点信息

为了尽可能快，Maglev尽可能多地一次性完成。与其在后期优化阶段构建通用JavaScript图并降低其复杂性，这是一种理论上干净但计算上昂贵的方法，Maglev在图构建过程中尽可能多地完成。

在图构建过程中，Maglev会查看在未优化执行期间收集的运行时反馈元数据，并为观察到的类型生成专门的SSA节点。如果Maglev看到o.x并从运行时反馈中知道o总是具有一个特定的形状，它将生成一个SSA节点，在运行时检查o是否仍然具有预期的形状，然后是一个廉价的LoadField节点，它通过偏移进行简单访问。

此外，Maglev会生成一个旁节点，现在它知道了o的形状，使得以后不再需要检查形状。如果Maglev后来遇到一个没有反馈的操作，这种在编译期间学到的信息可以作为第二个反馈来源。

运行时信息可以有多种形式。有些信息需要在运行时检查，比如之前描述的形状检查。其他信息可以通过注册对运行时的依赖而无需运行时检查。实际上不变的全局变量（在初始化和Maglev看到其值之间未更改）属于这一类：Maglev不需要生成代码来动态加载和检查它们的身份。Maglev可以在编译时加载值并将其直接嵌入机器代码中；如果运行时更改了该全局变量，它也会负责使该机器代码失效并进行去优化。

某些形式的信息是不稳定的。这种信息只能在编译器确定它不会更改的情况下使用。例如，如果我们刚刚分配了一个对象，我们知道它是一个新对象，可以完全跳过昂贵的写屏障。一旦有了另一个潜在的分配，垃圾收集器可能已经移动了对象，我们现在需要发出这样的检查。其他信息是稳定的：如果我们从未见过任何对象从具有某个特定形状过渡出去，那么我们可以注册对此事件的依赖（任何对象从该特定形状过渡出去），并且不需要重新检查对象的形状，即使是在调用具有未知副作用的未知函数之后。

去优化

鉴于Maglev可以使用在运行时检查的投机信息，Maglev代码需要能够进行去优化。为实现这一点，Maglev将抽象解释器帧状态附加到可以去优化的节点。此状态将解释器寄存器映射到SSA值。这种状态在代码生成期间变成元数据，提供从优化状态到未优化状态的映射。去优化器解释这些数据，从解释器帧和机器寄存器中读取值并将它们放入解释所需的位置。这建立在与TurboFan使用的相同的去优化机制之上，使我们能够共享大部分逻辑并利用现有系统的测试。

表示选择

根据规范，JavaScript数字表示64位浮点值。这并不意味着引擎必须总是将它们存储为64位浮点值，特别是因为实际上许多数字是小整数（例如数组索引）。V8尝试将数字编码为31位标记整数（内部称为“小整数”或“Smi”），以节省内存（由于指针压缩为32位），并提高性能（整数操作比浮点操作快）。

为了使数值密集的JavaScript代码运行得更快，选择值节点的最佳表示非常重要。与解释器和Sparkplug不同，优化编译器一旦知道类型，就可以取消值的装箱，操作原始数字而不是表示数字的JavaScript值，并且只有在绝对必要时才重新装箱。浮点数可以直接在浮点寄存器中传递，而不是分配包含浮点数的堆对象。

Maglev主要通过查看运行时反馈（例如二元操作）来了解SSA节点的表示，并通过已知节点信息机制向前传播这些信息。当具有特定表示的SSA值流入Phi节点时，需要选择支持所有输入的正确表示。循环Phi再次很棘手，因为循环内的输入在应为Phi选择表示之后看到——与图构建相同的“回到过去”问题。这就是为什么Maglev在图构建之后有一个单独的阶段来对循环Phi进行表示选择。

寄存器分配

在图构建和表示选择之后，Maglev大致知道它想生成什么样的代码，并且从经典的优化角度来看已经“完成”。然而，为了能够生成代码，我们需要选择SSA值在执行机器代码时的实际位置；它们何时在机器寄存器中，何时在堆栈上保存。这通过寄存器分配来完成。

每个Maglev节点都有输入和输出要求，包括对临时变量的要求。寄存器分配器对图进行单次前向遍历，维护一个与图构建期间维护的抽象解释状态非常相似的抽象机器寄存器状态，并满足这些要求，用实际位置替换节点的要求。这些位置随后可用于代码生成。

首先，预处理遍历图以找到节点的线性生命周期范围，以便我们可以在不再需要SSA节点时释放寄存器。此预处理还跟踪使用链。知道一个值在未来需要多长时间可以帮助我们决定优先考虑哪些值，以及在寄存器用完时放弃哪些值。

在预处理之后，寄存器分配运行。寄存器分配遵循一些简单的局部规则：如果一个值已经在寄存器中，则尽可能使用该寄存器。节点在图遍历过程中跟踪它们存储到的寄存器。如果节点尚未有寄存器，但有一个空闲寄存器，则选择它。节点会更新以指示它在寄存器中，并且抽象寄存器状态会更新以知道它包含节点。如果没有空闲寄存器但需要寄存器，则另一个值会被推出寄存器。理想情况下，我们有一个已经在不同寄存器中的节点，可以“免费”丢弃它；否则，我们选择一个不需要很长时间的值，并将其溢出到堆栈上。

在分支合并时，来自传入分支的抽象寄存器状态会合并。我们尽量保持尽可能多的值在寄存器中。这可能意味着我们需要引入寄存器到寄存器的移动，或者可能需要从堆栈中取消溢出值，使用称为“间隙移动”的移动。如果分支合并有一个Phi节点，寄存器分配将为Phi分配输出寄存器。Maglev倾向于将Phi的输出分配给与其输入相同的寄存器，以最小化移动。

如果Maglev帧中的SSA值比寄存器更多，我们将需要将一些值溢出到堆栈上，并在以后取消溢出。遵循Maglev的精神，我们保持简单：如果一个值需要溢出，它会被追溯告知在定义时立即溢出（在值创建之后），代码生成将处理发出溢出代码。定义保证“支配”所有值的使用（到达使用点必须经过定义点，因此经过溢出代码）。这也意味着溢出的值在代码的整个持续时间内将只有一个溢出槽；具有重叠生命周期的值将因此具有不重叠的分配溢出槽。

由于表示选择，Maglev帧中的某些值将是标记指针，V8的GC理解并需要考虑的指针；而某些值将是未标记的，GC不应查看的值。TurboFan通过精确跟踪哪些堆栈槽包含标记值，哪些包含未标记值来处理这一点，这在执行过程中会发生变化，因为槽被重新用于不同的值。对于Maglev，我们决定保持简单，以减少跟踪所需的内存：我们将堆栈帧分为标记和未标记区域，并且只存储这个分割点。

代码生成

一旦我们知道要为哪些表达式生成代码，以及要将它们的输出和输入放在哪里，Maglev就准备生成代码了。

Maglev节点直接知道如何使用“宏汇编器”生成汇编代码。例如，一个CheckMap节点知道如何发出汇编指令，将输入对象的形状（内部称为“映射”）与已知值进行比较，如果对象具有错误的形状，则进行去优化。

处理间隙移动的代码有些棘手：寄存器分配器创建的请求移动知道一个值在某处需要去另一个地方。然而，如果有一系列这样的移动，前面的移动可能会覆盖后续移动所需的输入。并行移动解析器计算如何安全地执行这些移动，以便所有值都能到达正确的位置。

结果

那么，我们刚刚介绍的编译器显然比Sparkplug复杂得多，但比TurboFan简单得多。它表现如何？

在编译速度方面，我们成功地构建了一个比Sparkplug慢约10倍，比TurboFan快约10倍的JIT。

JetStream中所有编译函数的编译时间比较

这使我们能够比想要部署TurboFan更早地部署Maglev。如果它依赖的反馈最终不太稳定，去优化和重新编译的成本并不高。这也使我们可以稍后使用TurboFan：我们运行的速度远快于使用Sparkplug。

将Maglev插入Sparkplug和TurboFan之间，带来了显著的基准测试改进：

包含Maglev的Web性能基准测试

我们还在实际数据上验证了Maglev，并在核心Web指标上看到了良好的改进。

由于Maglev编译速度更快，并且我们现在可以在编译TurboFan函数之前等待更长时间，这带来了一个不太明显的次要好处。基准测试关注主线程延迟，但Maglev也显著减少了V8的整体资源消耗，使用更少的线程外CPU时间。可以在基于M1或M2的Macbook上使用taskinfo轻松测量进程的能量消耗。

基准测试	能量消耗
JetStream	-3.5%
Speedometer	-10%

Maglev还远未完成。我们还有很多工作要做，还有更多的想法要尝试，还有更多的低垂果实要采摘——随着Maglev的完善，我们预计会看到更高的分数和更多的能量消耗减少。

Maglev现在已经可以在桌面版Chrome上使用，并将很快推广到移动设备。

←Back to home

This work is licensed under CC BY-NC-SA 4.0