共计 1623 个字符，预计需要花费 5 分钟才能阅读完成。
Sparkplug 的“前身”
V8 用的是一个绝对比拟快的 Full-codegen 编译器生成未优化的代码，而后通过 Crankshaft 这个及时（JIT）编译器对代码进行优化和反优化。
Full-codegen + Crankshaft 性能问题，对 JS 优化不现实。
V8 就引入了 Ignition 解释器和 TurboFan 的优化编译器以挪动优先为目标的流水线。通过 Ignition 最终生成字节码，之后再通过 TurboFan 生成优化后的代码，和做相干的反优化。
TurboFan 和 Crankshaft 比起来，显得有余。
V8 又创立了一个把 Full-codegen，Crankshaft，Ignition 和 TurboFan 整合起来的“全家桶”的流水线。
Sparkplug 的目标是疾速编译
首先，它编译的函数曾经被编译为字节码了。第二个办法是 Sparkplug 不会像 TurboFan 那样生成任何两头码 (IR)。
// Sparkplug 编译器的局部代码
for (; !iterator.done(); iterator.Advance()) {VisitSingleBytecode();
}栈指针和帧指针的应用
调用栈是代码执行存储函数状态的形式，而每当咱们调用一个新函数时，它都会为该函数的本地变量创立一个新的栈帧。栈帧由帧指针（标记其开始）和栈指针（标记其完结）定义。Sparkplug 采纳了与“与解释器兼容的栈帧”。
当该函数创立一个新栈帧时，也会将旧的帧指针保留在栈中，并将新的帧指针设置为它本人栈帧的结尾。
除了函数的本地变量和回调地址外，栈中还会有传参和储值。参数（包含接收者）在调用函数之前以相同的程序压入栈内，帧指针后面的几个栈槽是以后正在被调用的函数、上下文，以及传递的参数数量。这是“规范”JS 框架布局：
Ignition 解释器会进一步让调用约定变得更加明确。Ignition 是基于寄存器的解释器，和机器寄存器的不同在于它是一个虚构寄存器。它的作用是存储解释器的以后状态。包含 JavaScript 函数局部变量（var/let/const 申明）和长期值。
栈帧中还有一个指向正在执行的字节码数组的指针，以及以后字节码在该数组中的偏移量。
起初，V8 团队对解释器栈帧做了一个小改变，就是 Sparkplug 在代码执行期间不再保留最新的字节码偏移量，改为了存储从 Sparkplug 代码地址范畴到相应字节码偏移量的双向映射。
Sparkplug 特意创立并保护与解释器相匹配的栈帧布局；每当解释器存储一个寄存器值时，Sparkplug 也会存储一个。
它这样做有几点益处，一是简化了 Sparkplug 的编译, Sparkplug 能够只镜像解释器的行为，而不用保留从解释器寄存器到 Sparkplug 状态的映射。二是它还放慢了编译速度，因为字节码编译器曾经实现了寄存器调配的繁琐的工作。三是它与零碎其余部分（如调试器、分析器）的集成是根本适配的。四是任何实用于解释器的栈替换（OSR，on-stack replacement）的逻辑都实用于 Sparkplug；并且解释器和 Sparkplug 代码之间替换的栈帧转换老本简直为零。
Sparkplug 尽管和解释器做简直同样的工作。只是解释器执行的序列化，调用雷同的内置性能并保护雷同的栈帧。
Sparkplug 也是有价值的，因为它打消了或更谨严地说，预编译了那些无奈打消的解释器老本，因为实际上，解释器影响了许多 CPU 优化。
例如操作符解码和下一个字节码调度。解释器从内存中动静读取动态操作符，导致 CPU 要么进行，要么揣测值可能是什么；分派到下一个字节码须要胜利的分支预测能力放弃性能，即便揣测和预测是正确的，依然必须执行所有解码和分派代码，后果仍然是用尽了各种缓冲区中的贵重空间和缓存。只管 CPU 用于机器码，但自身实际上就是一个解释器。从这个角度看，Sparkplug 其实是一个从 Ignition 到 CPU 字节码的“转换器”，将函数从“模拟器”中转移到“本机”运行。
