Ignition: 快速启动的 V8 解释器 #

目录 #

原文 #

为什么我们钟情于 JavaScript #

• Web 的语言
• 程序由源代码发布，paring 和 compiling 必须足够快
• 无类型：变量和属性都没有类型，值是由类型
• 基于原型链的 object 模型
• 闭包（closures）带来的函数式特性
• 一些有趣的功能
  • Eval () 支持在函数中动态执行运行时生成的语句
  • 奇怪的作用域（scoping）规则
  • 默认值和隐式类型转换
  • ...

简单示例 #

语义一瞥 #

万物皆函数 #

除非存在闭包 #

有趣的 eval () #

V8 方法 #

V8 历史 #

省略。

Full-Codegen 简述 #

Hidden Classes #

Inline Caches (ICs) #

Crankshaft 一瞥 #

Deoptimization - 永远有个备用方案 #

• 在推测优化之前插入反优化点

• Crankshaft 需要为反优化点重建一个堆帧来模拟 Full-Codegen 的执行

TurburFan - 另一个 Optimizing Compiler？ #

Crankshaft 很好，但是有一些缺点：

• 无法扩展到全部的现代的 JavaScript
  • try-catch, for-of, generators, async/await
• 高度依赖于 deoptimization
  • 性能缺陷和反优化循环
• 受限的类型分析和传播
  • 不适合 asm.js 风格的优化
• 和 Full-codegen 紧耦合
• 高移植（porting）负载

TurboFan #

• 节点海（Sea of Nodes）
  • 放宽大多数操作的求值顺序 (值边)
  • CFG 的骨架 (控制边) 和状态操作 (副作用边)
  • 提供更好的冗余代码消除和更多的代码移动
• 三级 IR
  • JavaScript：JavaScript 过载的操作符
  • 简化：虚拟机操作，如分配、数字运算等
  • 机器：机器级操作，例如 int32 加法

Sea of Nodes #

把解释器改装成移动的引擎 #

为什么需要解释 #

参见：V8: 连接 Ignition 与 Turbofan

Ignition 的目标 #

• 减少内存使用量
  • 编译为字节码比机器码小 4x。
  • 减少总共的代码内存占用 2x。
• 减少启动时间
  • 更快的编译为字节码
  • 减少延迟编译的重新解析，优化重新编译
• 降低复杂性
  • 字节码作为真实的来源
  • 简化编译管道

Ignition 的挑战 #

• 不能降低性能
• 在 9 种 CPU 架构上 100% 支持 JavaScript。
• 与 V8 运行时结合（类型反馈、object 模型、GC 等等）。
• 支持 debugger 和实时编辑
• 支持两种 pipelines（Crankshaft 和 TurboFan）

Ignition 的设计决策 #

• 聚焦于降低代码体积
  • 间接线程字节码分发
  • 累加器作为隐式输入 / 输出
• 仍然保持足够快的数速度
  • 使用宏汇编语言（体系结构无关的）的手工编码
  • 寄存器机器
• 字节码可以直接用于构建 TurboFan 图
  • 字节码是唯一数据源
  • 更简单的去优化执行模型

Ignition 字节码 #

Ignition Bytecode Pipeline #

构建 Ignition 解释器 #

• C++ 编写
  • Need trampolines between Interpreted and JITed functions
  • Can’t interoperate with fast code-stubs
• 手工编写的汇编代码
  • 需要适配 9 种架构
• 以 TurboFan Compiler 为后端
  • 宏汇编一次编写
  • 自由的架构特定指令选择优化
  • 与现有代码存根（code-stubs）的相对轻松的互操作性

TurboFan Pipeline #

总结 #

• JavaScript 很难
• V8 很复杂
• 解释器 (有时) 可以击败 JIT…… 但这需要很多工作！

Ignition Bytecodes #

参考 #

• DLS Keynote: Ignition: Jump-starting an Interpreter for V8 - Google Slides