5 年了，V8 引擎发生了什么新变化

5 年了V8 引擎发生了什么新变化我在 2021 年写过一篇讲 V8 引擎的文章覆盖了编译执行流程Ignition TurboFan、deopt、垃圾回收引用计数、标记清除、分代、增量标记等。这几年 V8 变化不小——尤其是编译流水线从两层长成了四层。这篇不重复旧文的基础内容只讲这 5 年发生的新变化读之前建议先有旧文那些概念打底。原文链接聊聊v8引擎一、最大的变化编译流水线从两层变成四层旧架构两层的断层问题先回顾旧文的架构。2021 年之前V8 是经典的两层Ignition解释器把 JS 编译成字节码并逐条解释执行。启动快但执行慢。TurboFan顶级优化编译器把热点代码 JIT 编译成高度优化的机器码。执行快但编译慢、成本高。这套结构有个明显的断层Ignition 太慢TurboFan 又太贵。中间缺了过渡档位。现实网页里大量函数是温热的——被执行了不少次值得比解释执行快一点但又没热到值得花 TurboFan 的重成本去深度优化。旧架构对这些温热代码无能为力要么让它在解释器里慢慢跑要么砸重金优化它没有中间选项。这 5 年V8 在中间塞进了两个新编译器把断层填平了。现在完整的四层流水线是Ignition → Sparkplug → Maglev → TurboFan 解释器 基线编译 快速优化 顶级优化 最慢 ↓ ↓ 最快 编译最省 越往右生成的机器码越快但编译成本越高代码随着执行次数增加、“越来越热”就沿着这条流水线逐级向右升级这个过程叫分层递进优化tiering up。下面逐个讲两个新成员。新成员一Sparkplug基线编译器2021Sparkplug 补在 Ignition 之上它的设计目标只有一个词——快到几乎瞬间地编译。它不做任何复杂优化只是把字节码近乎一比一地翻译成等价的机器码。为什么不优化也有价值因为哪怕只是把解释执行字节码换成直接跑机器码就已经省掉了解释器逐条分发指令的开销。而且因为它编译成本极低V8 可以大范围地给几乎所有代码都套上这一层稳定地拿到一档加速。它的性能收益很实在在 JetStream 基准上Sparkplug 相比纯 Ignition 提升约 45%在更贴近真实网页的 Speedometer 上相比 Ignition 提升约 41%甚至相比Ignition TurboFan的旧组合还能再快约 22%。新成员二Maglev快速优化编译器2023Sparkplug 快是快但因为完全不优化天花板很低——它和 TurboFan 之间还是隔着一道大鸿沟。Maglev 就是来填这道鸿沟的。Maglev 位于 Sparkplug 和 TurboFan 之间扮演快速的优化编译器它生成的代码比 Sparkplug 好得多因为它真的做优化但生成速度又远快于 TurboFan因为它的优化比 TurboFan 轻量。这里有个值得记住的技术细节也是面试深水区的好素材——Maglev 和 TurboFan 用了不同的内部表示IRTurboFan用的是节点之海sea-of-nodes——非常灵活、能做激进优化但结构复杂、对 CPU 缓存不友好、编译慢。Maglev用的是更传统的SSA静态单赋值 控制流图CFG——结构更简单、编译更快优化能力介于 Sparkplug 和 TurboFan 之间。Maglev 同样会做投机优化、也能 deopt它复用了 TurboFan 那套去优化机制所以旧文讲的 deopt 概念在这里完全适用只是整体更轻、更快。为什么要这么设计分层优化的哲学把四层串起来看V8 的思路是按代码的热度精准投放优化资源代码刚开始跑 → Ignition 解释执行启动最快不浪费编译成本跑了一些次数温热→ Sparkplug 给一层免费的机器码更热了 → Maglev 花点小成本做中等优化滚烫的热点 → TurboFan 砸重成本做极致优化。这解决的正是旧架构的断层每一档热度都有性价比合适的优化档位接着不再是要么太慢、要么太贵的二选一。这套tiering up思想是理解现代 V8 性能表现的钥匙。二、垃圾回收从增量到并发/并行旧文的 GC 部分讲了引用计数、标记清除、分代、全停顿、增量标记、延迟清理、增量整理。这几年 GC 又有两个重要进展值得补上。补充一并行与并发Orinoco 项目旧文提到的增量标记是减少全停顿的第一招——把标记拆成小片穿插进主线程空隙。但现代 V8 的 GC统称Orinoco项目把三种手段结合了起来这三个词经常被混用务必分清增量incremental把 GC 工作拆成小块穿插在主线程的空闲间隙做。主线程还是要停但每次停得短。并行parallel主线程和多个辅助线程同时干 GC 的活。主线程仍需暂停但因为多线程一起干暂停时间大幅缩短。并发concurrent辅助线程在主线程照常运行 JS 的同时在后台默默做标记。主线程几乎不用停。现代 V8 的组合大致是新生代用并行 Scavenge老生代用并发标记 并行清理/整理。这是旧文那个全停顿问题在这几年的进一步解法——从拆小片穿插进化到多线程后台并发处理主线程卡顿被压到了更低。补充二Oilpan —— 连 C 对象也有了 GC旧文讲的是 JS 堆的垃圾回收。但这几年 V8 单独发展出了一套Oilpan代码里叫 cppgc——给 C 对象用的垃圾回收器。这是干嘛的浏览器里很多东西比如 DOM 节点底层是用 C 实现的对象它们的内存也需要管理。Oilpan 就是给这些 C 对象做自动回收的。对前端来说这是个能加分的认知你操作的 DOM 节点它的生命周期其实也被一套C 的GC 管理着——浏览器的内存管理不止 JS 堆这一层。三、内存与安全两个新方向补充一指针压缩Pointer Compression2020问题64 位系统上每个指针占 8 字节对象里到处是指针很占内存。V8 的观察是——堆通常不会超过 4GB那么用 32 位就足够寻址了。于是 V8只存 32 位的偏移量相对于一个基地址把指针从 8 字节压到 4 字节。效果V8 堆内存显著下降约 40%对内存受限的移动设备尤其重要。顺带解释一个概念——SmiSmall Integer小整数V8 把小整数用带标记的 31 位直接内联存进指针位置不用在堆上单独分配对象既省内存又快。指针压缩正是和 Smi 这套编码配合工作的。补充二V8 SandboxV8 沙箱2024这是 V8 安全方向的大事也回应了一个现实矛盾V8 为了极致性能用了大量底层优化JIT、内联缓存、指针压缩等而这些优化面恰恰是内存漏洞的高发区。任何一个边界检查疏忽、类型转换错误都可能被利用成内存破坏漏洞。V8 Sandbox 是一道新防线它把 V8 堆的内存访问限制在一个受控的沙箱区域内。即便攻击者利用漏洞篡改了堆内对象也很难逃逸到整个进程的地址空间去执行任意代码。配合另一项Control-flow Integrity控制流完整性V8 在性能 vs 安全这场持久博弈里补强了安全侧。四、几个小而重要的变化发布博客停了。V8 从 2022 年 6 月起不再为每个版本单独写发布博客了。现在想跟进新特性要看 v8.dev 的 feature 页和 Chrome 的发布说明。JIT-less 模式。V8 支持完全不生成机器码、纯 Ignition 解释执行的模式。用在 iOS 这类出于安全禁止运行时生成可执行代码的平台上。这解释了一个现象——同样是 V8在 iOS 上的表现可能和别处不同因为它跑在 JIT-less 模式下吃不到那几层编译器的加速。一批具体的性能专题可作延伸阅读更快的 async/await 和 Promise、super属性访问加速、JSON.stringify提速一倍多、堆快照heap snapshot速度大幅提升——最后这条正好和旧文的 GC / DevTools 内存分析呼应抓内存泄漏更快了。资源所有更新都可以在 V8 官方博客 https://v8.dev/blog 找到一手出处Sparkplug、Maglev、指针压缩、Oilpan、Sandbox 都有专文。注意逐版本发布博客已于 2022 年停更新特性改看 v8.dev 的 features 页。