精讀《JS 引擎基礎之 Shapes and Inline Caches》

1 引言

本期精讀的文章是：JS 引擎基礎之 Shapes and Inline Caches

一塊兒瞭解下 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 與數據分離的方式存儲：

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 引擎對數組下標作了額外優化。

5 更多討論

討論地址是： 精讀《JS 引擎基礎之 Shapes and Inline Caches》 · Issue #91 · dt-fe/weekly

若是你想參與討論，請點擊這裏，每週都有新的主題，週末或週一發佈。