JS 引擎基础之 Shapes and Inline Caches

阅读下面这篇文章，须要20分钟:

 

 

一块儿了解下 JS 引擎是如何运做的吧！

JS 的运做机制能够分为 AST 分析、引擎执行两个步骤：

JS 源码经过 parser（分析器）转化为 AST（抽象语法树），再通过 interperter（解释器）解析为 bytecode（字节码）。

为了提升运行效率，optimizing compiler（优化编译器）负责生成 optimized code（优化后的机器码）。

本文主要从 AST 以后提及。

2 概述

JS 的解释器、优化器

JS 代码可能在字节码或者优化后的机器码状态下执行，而生成字节码速度很快，而生成机器码就要慢一些了。

 

V8 也相似，V8 将 interpreter 称为 Ignition（点火器），将 optimizing compiler 成为 TurboFan（涡轮风扇发动机）。

 

 

 

能够理解为将代码先点火启动后，逐渐进入涡轮发动机提速。

代码先快速解析成可执行的字节码，在执行过程当中，利用执行中获取的数据（好比执行频率），将一些频率高的方法，经过优化编译器生成机器码以提速。

 

火狐使用的 Mozilla 引擎有一点点不一样，使用了两个优化编译器，先将字节码优化为部分机器码，再根据这个部分优化后的代码运行时拿到的数据进行最终优化，生成高度优化的机器码，若是优化失败将会回退到部分优化的机器码。

笔者：不一样前端引擎对 JS 优化方式大同小异，后面会继续列举不一样前端引擎在解析器、编译器部分优化的方式。

微软的 Edge 浏览器，使用的 Chakra 引擎，优化方式与 Mozilla 很像，区别是第二个最终优化的编译器同时接收字节码和部分优化的机器码产生的数据，而且在优化失败后回退到第一步字节码而不是第二步。

Safari、React Native 使用的 JSC 引擎则更为极端，使用了三个优化编译器，其优化是一步步渐进的，优化失败后都会回退到第一步部分优化的机器码。

为何不一样前端引擎会使用不一样的优化策略呢？这是因为 JS 要么使用解释器快速执行（生成字节码），或者优化成机器码后再执行，但优化消耗时间的并不老是小于字节码低效运行损耗的时间，因此有些引擎选择了多个优化编译器，逐层优化，尽量在解析时间与执行效率中找到一个平衡点。

JS 的对象模型

JS 是基于面向对象的，那么 JS 引擎是如何实现 JS 对象模型的呢？他们用了哪些技巧加速访问 JS 对象的属性？

和解析器、优化器同样，大部分主流 JS 引擎在对象模型实现上也很相似

 

 

ECMAScript 规范肯定了对象模型就是一个以字符串为 key 的字典，除了其值之外，还定义了 Writeable Enumerable Configurable 这些配置，表示这个 key 可否被重写、遍历访问、配置。

虽然规范定义了 [[]] 双括号的写法，那这不会暴露给用户，暴露给用户的是 Object.getOwnPropertyDescriptor 这个 API，能够拿到某个属性的配置。

 

在 JS 中，数组是对象的特殊场景，相比对象，数组拥有特定的下标，根据 ECMAScript 规范规定，数组下标的长度最大为 2³²−1。同时数组拥有  length 属性：

length 只是一个不可枚举、不可配置的属性，而且在数组赋值时，会自动更新数值：

因此数组是特殊的对象，结构彻底一致。

属性访问效率优化

属性访问是最多见的，因此 JS 引擎必须对属性访问作优化。

Shapes

JS 编程中，给不一样对象相同的 key 名很常见，访问不一样对象的同一个 propertyKey 也很常见：

const object1 = { x: 1, y: 2 }; const object2 = { x: 3, y: 4 }; function logX(object) { console.log(object.x); // ^^^^^^^^ } logX(object1); logX(object2); 

这时 object1 与 object2 拥有一个相同的 shape。拿拥有 x、y 属性的对象来看：

若是访问 object.y，JS 引擎会先找到 key y，再查找 [[value]]。

若是将属性值也存储在 JSObject 中，像 object1 object2 就会出现许多冗余数据，所以引擎单独存储 Shape，与真实对象隔离：

这样具备相同结构的对象能够共享 Shape。全部 JS 引擎都是用这种方式优化对象，但并不都称为 Shape，这里就不详细罗列了，能够去原文查看在各引擎中 Shape 的别名。

Transition chains 和 Transition trees

若是给一个对象增长了 key，JS 引擎如何生成新的 Shape 呢？

这种 Shape 链式建立的过程，称为 Transition chains:

开始建立空对象时，JSObject 和 Shape 都是空，当为 x 赋值 5 时，在 JSObject 下标 0 的位置添加了 5，而且 Shape 指向了拥有字段 x 的 Shape(x)，当赋值 y 为 6 时，在 JSObject 下标 1 的位置添加了 6，并将 Shape 指向了拥有字段 x 和 y 的 Shape(x, y)。

并且能够再优化，Shape(x, y) 因为被 Shape(x) 指向，因此能够省略 x 这个属性：

笔者：固然这里说的主要是优化技巧，咱们能够看出来，JS 引擎在作架构设计时没有考虑优化问题，而在架构设计完后，再回过头对时间和空间进行优化，这是架构设计的通用思路。

若是没有连续的父 Shape，好比分别建立两个对象：

const object1 = {}; object1.x = 5; const object2 = {}; object2.y = 6; 

这时要经过 Transition trees 来优化：

能够看到，两个 Shape(x) Shape(y) 别分继承 Shape(empty)。固然也不是任什么时候候都会建立空 Shape，好比下面的状况：

const object1 = {}; object1.x = 5; const object2 = { x: 6 }; 

生成的 Shape 以下图所示：

能够看到，因为 object2 并非从空对象开始的，因此并不会从 Shape(empty) 开始继承。

Inline Caches

大概能够翻译为“局部缓存”，JS 引擎为了提升对象查找效率，须要在局部作高效缓存。

好比有一个函数 getX，从 o.x 获取值：

function getX(o) { return o.x; } 

JSC 引擎 生成的字节码结构是这样的：

get_by_id 指令是获取 arg1 参数指向的对象 x，并存储在 loc0，第二步则返回 loc0。

当执行函数 getX({ x: 'a' }) 时，引擎会在 get_by_id 指令中缓存这个对象的 Shape：

这个对象的 Shape 记录了本身拥有的字段 x 以及其对应的下标 offset：

执行 get_by_id 时，引擎从 Shape 查找下标，找到 x，这就是 o.x 的查找过程。但一旦找到，引擎就会将 Shape 保存的 offset 缓存起来，下次开始直接跳过 Shape 这一步：

之后访问 o.x 时，只要 Shape 相同，引擎直接从 get_by_id 指令中缓存的下标中能够直接命中要查找的值，而这个缓存在指令中的下标就是 Inline Cache.

数组存储优化

和对象同样，数组的存储也能够被优化，而因为数组的特殊性，不须要为每一项数据作完整的配置。

好比这个数组：

const array = ["#jsconfeu"]; 

JS 引擎一样经过 Shape 与数据分离的方式存储：

数组存储优化

和对象同样，数组的存储也能够被优化，而因为数组的特殊性，不须要为每一项数据作完整的配置。

好比这个数组：

const array = ["#jsconfeu"]; 

JS 引擎一样经过 Shape 与数据分离的方式存储：

JS 引擎将数组的值单独存储在 Elements 结构中，并且它们一般都是可读可配置可枚举的，因此并不会像对象同样，为每一个元素作配置。

但若是是这种例子：

// 永远不要这么作 const array = Object.defineProperty([], "0", { value: "Oh noes!!1", writable: false, enumerable: false, configurable: false }); 

JS 引擎会存储一个 Dictionary Elements 类型，为每一个数组元素作配置：

这样数组的优化就没有用了，后续的赋值都会基于这种比较浪费空间的 Dictionary Elements 结构。因此永远不要用 Object.defineProperty 操做数组。

经过对 JS 引擎原理的认识，做者总结了下面两点代码中的注意事项：

1. 尽可能以相同方式初始化对象，由于这样会生成较少的 Shapes。
2. 不要混淆对象的 propertyKey 与数组的下标，虽然都是用相似的结构存储，但 JS 引擎对数组下标作了额外优化。

3 精读

此次原理系列解读是针对 JS 引擎执行优化这个点的，而网页渲染流程大体以下：

能够看到 Script 在整个网页解析链路中位置是比较靠前的，JS 解析效率会直接影响网页的渲染，因此 JS 引擎经过解释器（parser）和优化器（optimizing compiler）尽量  对 JS 代码提效。

Shapes

须要特别说明的是，Shapes 并非  原型链，原型链是面向开发者的概念，而 Shapes 是面向 JS 引擎的概念。

好比以下代码：

const a = {}; const b = {}; const c = {}; 

显然对象 a b c 之间是没有关联的，但共享一个 Shapes。

另外理解引擎的概念有助于咱们站在语法层面对立面的角度思考问题：在 JS 学习阶段，咱们会执着于思考以下几种建立对象方式的异同：

const a = {}; const b = new Object(); const c = new f1(); const d = Object.create(null); 

好比上面四种状况，咱们要理解在什么状况下，用何种方式建立对象性能最优。

但站在 JS 引擎优化角度去考虑，JS 引擎更但愿咱们都经过 const a = {} 这种看似最没有难度的方式建立对象，由于能够共享 Shape。而与其余方式混合使用，可能在逻辑上作到了优化，但阻碍了 JS 引擎作自动优化，可能会得不偿失。

Inline Caches

对象级别的优化已经很极致了，工程代码中也没有机会帮助 JS 引擎作得更好，值得注意的是不要对数组使用 Object 对象下的方法，尤为是 defineProperty，由于这会让 JS 引擎在存储数组元素时，使用 Dictionary Elements 结构替代 Elements，而 Elements 结构是共享 PropertyDescriptor 的。

但也有难以免的状况，好比使用 Object.defineProperty 监听数组变化时，就不得不破坏 JS 引擎渲染了。

笔者写 dob 的时候，使用 proxy 监听数组变化，这并不会改变 Elements 的结构，因此这也从另外一个侧面证实了使用 proxy 监听对象变化比 Object.defineProperty 更优，由于 Object.defineProperty 会破坏 JS 引擎对数组作的优化。

4 总结

本文主要介绍了 JS 引擎两个概念： Shapes 与 Inline Caches，经过认识 JS 引擎的优化方式，在编程中须要注意如下两件事：

1. 尽可能以相同方式初始化对象，由于这样会生成较少的 Shapes。
2. 不要混淆对象的 propertyKey 与数组的下标，虽然都是用相似的结构存储，但 JS 引擎对数组下标作了额外优化。