JS 引擎 (1):JS 引擎擂台赛，JavaScript 引擎的特征比较及术语科普

上篇介绍过 JavaScript 引擎的历史，《JS引擎(0):起底各种JavaScript引擎群雄争霸之路》

一些流行的 JavaScript 引擎

• SpiderMonkey ，Brendan Eich 在 Netscape 创建，由 C/C++ 语言开发，可适配 ECMA-262 Edition 5 及其之后的标准版本

• Rhino，由 Norris Boyd（归属 Netscape）创建，则是一个 Java 语言开发的 JavaScript 实现，跟 SpiderMonkey 

• Google 的 V8，在 Google Chrome 浏览器和较新的 Opera 浏览器中使用。这同时也是Node.js使用的引擎。

• JavaScriptCore (SquirrelFish/Nitro)，被用在了一些 WebKit 浏览器如 Apple Safari。

• Carakan，用在旧版本 Opera 中。

• The Chakra 引擎

几种较老的 JavaScript 引擎的特征：

不懂的术语，可以跳转至 JavaScript引擎相关关术语解析

在 Google 推出 V8 之后，业界受到巨大冲击。V8 的性能远高于当时所有其它 JavaScript 引擎，可以有效支撑起当时兴起的大量使用 JavaScript 的 Web 应用。

各大 JavaScript 引擎的实现者都坐不住了，像打了鸡血似的使劲优化优化再优化。先是把已在其它 HLLVM 上得到充分验证的优化技术引入到 JavaScript 引擎中，然后再针对 JavaScript 语言的特点做专项优化。

现在（2013-04）几种主流的 JavaScript 引擎的特征：

JavaScript 引擎相关术语解析

• 树遍历解释器：tree-walking interpreter。遍历抽象语法树来解释执行的解释器。

• 对象布局: object representation 或者 object layout。指在堆上分配的 JavaScript 对象的在内存中的布局。

• 值表现形式: value representation。注意跟“对象布局”说的不是一件事。这个指的是原始类型数据、指向堆上分配的对象的指针之类的值的表现形式。对某些 JavaScript 引擎来说这是指“JSValue”背后在内存中的表现形式。新生代中的对象 98%是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性的复制到另外一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性的复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用内存为整个新生代容量的 90%（80%+10%），只有 10%的内存会被“浪费”。

• copying GC: 也叫 scavenger。垃圾收集算法——复制算法，他将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

  现在的商业虚拟机都采用这种收集算法来回收新生代，这种算法的代价是将内存缩小为了原来的一半

  IC，Inline caching，内联缓存。实际上是一门近 30 年的非常古老的技术，最初用在 Smalltalk 虚拟机上。工作原理：创建一个高速路来绕过运行时系统来读取对象的属性:对传入的对象及其属性作出某种假设，然后通过一个低成本的方式验证这个假设是否正确，如果正确就读取上次缓存的结果。在充满了动态类型和晚绑定以及其他古怪行为——比如 eval——的语言里对一个对象作出合理的假设是非常困难的，所以我们退而求其次，让我们的读／写操作能够有学习能力：一旦它们看见某个对象它们就可以以某种方式来自适应，使得之后的读取操作在遇到类似结构的对象时能够更快地进行。在某种意义上，我们将要在读／写操作上缓存关于之前见过的对象的布局的相关知识——这也是内联缓存这个名字的由来。内联缓存可以被用在几乎所有需要动态行为的操作上，只要你可以找到正确的高速路：算数操作、调用自由函数、方法调用等等。有些内联缓存还能缓存不止一条快速通道，这些内联缓存就变成了多态的。

  MIC: monomorphic inline-cache，单态内联缓存。有一个简单的直接类型检查开销，然后是普通的直接调用开销。

• PIC: polymorphic inline-cache，多态内联缓存。

• pun-boxing: Packed NaN unboxing，SpiderMonkey 和 LuaJIT 似乎都在用 pun boxing

当代 JavaScript 引擎之间有许多共通的实现技巧

当代 JavaScript 引擎之间有许多共通的实现技巧。多数优化会对 JavaScript 程序的行为做一定猜测（speculate），并基于猜测做激进优化（speculative optimization）。下面挑几个简单介绍一下。

从源语言到中间表示的编译器（source-to-IR compiler）

  也叫做编译器的“前端”。

  递归下降式语法分析器（recursive-descent parser）

  运算符优先级式语法分析器（operator precedence parser）

  deferred parser / diet parser（延迟语法分析）

从中间表示到目标代码的编译器（IR-to-target-code compiler）

  也叫做编译器的“后端”。但因为这部分编译器经常被叫做“JIT”编译器，所以单独拿出来写

  JIT style compiler: “just-in-time 编译”狭义的定义是“即时编译”，也就是在某段代码即将第一次被执行时才对其编译。太早或太迟都不符合这个狭义版定义。所谓“JIT 风格的编译器”通常意味着“编译是同步进行的”。这就自然的引出几个特征：

1. 编译速度必须很快；

2. 编译只能做有限的优化，只能选效费比高的来做。

optimizing compiler

• 多层编译（tiered compilation）

• 后台编译（background compilation）

• 类型反馈（type feedback）

• 类型特化（type specialization）

• SSA-form IR

自动内存管理

• 分代式 GC（generational GC）

• 增量式 GC（incremental GC）

• 并发式 GC（concurrent GC）

• 准确式 GC（exact / accurate / type exact / type accurate / precise GC）

对象布局

• 紧凑对象布局 + 隐藏类

值表现形式

• tagger-pointer 或 tagged-value

• NaN-boxing

运行时系统

• inline-cache

• on-stack replacement

• deoptimization

• 用 native stack 实现 VM stack

• cons-string 或者叫 rope 来优化字符串拼接

• dependent string/sliced string 来优化字符串的子串操作

• sparse array

• B-tree

上面介绍的 JavaScript 引擎实现技巧也影响了“如何写出更高效的 JavaScript 代码”：尽量让代码的行为符合 JavaScript 引擎的猜测，效率就会高。

写类型稳定的代码

• 在构造器函数里声明和初始化所有属性

• 尽量不要 delete 属性；不要通过 delete 属性来把某个属性重置，赋值为 undefined 都好

• 不要把数组当一般对象用；不要把一般对象当数组用

参考内容：

各 JavaScript 引擎的简介，及相关资料/博客收集帖 https://hllvm-group.iteye.com/group/topic/37596

转载本站文章《JS引擎(1):JS引擎擂台赛，JavaScript引擎的特征比较及术语科普》,请注明出处：https://www.zhoulujun.cn/html/webfront/browser/webkit/2020_0718_8522.html