深入了解JavaScript引擎精華

作者：hijiangtao譯 2018-06-22 13:05:02

開發前端

本文來自 Google 引擎 V8 工程師 Mathias 和 Benedikt 在 JSConf EU 2018 上的演講。他們對所有 JavaScript 引擎中常見的一些關鍵基礎內容進行了介紹。

[[233743]]

本文來自 Google 引擎 V8 工程師 Mathias 和 Benedikt 在 JSConf EU 2018 上的演講。他們對所有 JavaScript 引擎中常見的一些關鍵基礎內容進行了介紹。

作為一名 JavaScript 開發者，深入了解 JavaScript 引擎是如何工作的將有助于你了解自己所寫代碼的性能特征。

全文共由五個部分組成：

1.JavaScript 引擎工作流程：介紹 JavaScript 引擎的處理流水線，這一部分會涉及到解釋器／編譯器的內容，且會分點介紹不同引擎間的差別與共同點；

2.JavaScript 對象模型；

3. 屬性訪問的優化：通過 Shapes、Transistion 鏈與樹、ICs 等概念的穿插介紹引擎是如何優化獲取對象屬性的；

4. 高效存儲數組；

5.Take-aways：對全文內容做了一個小結，并給了兩點建議。

JavaScript 引擎工作流程

JavaScript 引擎在解析源碼后將其轉換為抽象語法樹（AST），基于 AST，解釋器便可以開始工作并產生字節碼，此時引擎正在執行 JavaScript 代碼。

為了使它執行得更快，可以將字節碼與分析數據（profiling data）一起發給優化編譯器。優化編譯器根據已有的分析數據做出特定假設，然后生成高度優化的機器碼。

如果在某點上一個假設被證明是不正確的，那么優化編譯器會去優化并回退至解釋器部分。

JavaScript 引擎中的解釋器 / 編譯器流程

現在，讓我們關注實際執行 JavaScript 代碼的這部分流程，即代碼被解釋和優化的地方，并討論其在主要的 JavaScript 引擎之間存在的一些差異。

一般來說，所有 JavaSciript 引擎都有一個包含解釋器和優化編譯器的處理流程。其中，解釋器可以快速生成未優化的字節碼，而優化編譯器會需要更長的時間，以便最終生成高度優化的機器碼。

這個通用流程幾乎與在 Chrome 和 Node.js 中使用的 V8 引擎工作流程一致：

V8 中的解釋器被稱作 Ignition，它負責生成并執行字節碼。當它運行字節碼時會收集分析數據，而它之后可以被用于加快（代碼）執行的速度。當一個函數變得 hot，例如它經常被調用，生成的字節碼和分析數據則會被傳給 TurboFan——我們的優化編譯器，它會依據分析數據生成高度優化的機器碼。

SpiderMonkey，在 Firefox 和 SpiderNode 中使用的 Mozilla 的 JavaScript 引擎，則有一些不同的地方。它們有兩個優化編譯器。解釋器將代碼解釋給 Baseline 編譯器，該編譯器可以生成部分優化的代碼。結合運行代碼時收集的分析數據，IonMonkey 編譯器可以生成高度優化的代碼。如果嘗試優化失敗，IonMonkey 將回退到 Baseline 階段的代碼。

Chakra，用于 Edge 和 Node-ChakraCore 兩個項目的微軟 JavaScript 引擎，也有類似兩個優化編譯器的設置。解釋器將代碼優化成 SimpleJIT——其中 JIT 代表 Just-In-Time 編譯器——它可以生成部分優化的代碼。結合分析數據，FullJIT 可以生成更深入優化的代碼。

JavaScriptCore（縮寫為 JSC），Apple 的 JavaScript 引擎，被用于 Safari 和 React Native 兩個項目中，它通過三種不同的優化編譯器使效果達到***。低級解釋器 LLInt 將代碼解釋后傳遞給 Baseline 編譯器，而（經過 Baseline 編譯器）優化后的代碼便傳給了 DFG 編譯器，（在 DFG 編譯器處理后）結果最終傳給了 FTL 編譯器進行處理。

為什么有些引擎會擁有更多的優化編譯器呢？這完全是一些折衷的取舍。解釋器可以快速生成字節碼，但字節碼通常不夠高效。另一方面，優化編譯器處理需要更長的時間，但最終會生成更高效的機器碼。到底是快速獲取可執行的代碼（解釋器），還是花費更多時間但最終以***性能運行代碼（優化編譯器），這其中包含一個平衡點。一些引擎選擇添加具有不同耗時 / 效率特性的多個優化編譯器，以更高的復雜性為代價來對這些折衷點進行更細粒度的控制。

我們剛剛強調了每個 JavaScript 引擎中解釋器和優化編譯器流程中的主要區別。除了這些差異之外，所有 JavaScript 引擎都有相同的架構：那就是擁有一個解析器和某種解釋器 / 編譯器流程。

JavaScript 對象模型

通過關注一些方面的具體實現，讓我們來看看 JavaScript 引擎間還有哪些共同之處。

例如，JavaScript 引擎是如何實現 JavaScript 對象模型的，以及他們使用了哪些技巧來加快獲取 JavaScript 對象屬性的速度？事實證明，所有主要引擎在這一點上的實現都很相似。

ECMAScript 規范基本上將所有對象定義為由字符串鍵值映射到 property 屬性的字典。

除 [[Value]] 外，規范還定義了如下屬性：

[[Writable]] 決定該屬性是否可以被重新賦值；
[[Enumerable]] 決定該屬性是否出現在 for-in 循環中；
[[Configurable]] 決定該屬性是否可被刪除。

[[雙方括號]] 的符號表示看上去有些特別，但這正是規范定義不能直接暴露給 JavaScript 的屬性的表示方法。在 JavaScript 中你仍然可以通過 Object.getOwnPropertyDescriptor API 獲得指定對象的屬性值：

const object = { foo: 42 };  
Object.getOwnPropertyDescriptor(object, 'foo');  
// → { value: 42, writable: true, enumerable: true, configurable: true }

JavaScript 就是這個定義對象的，那么數組呢？

你可以將數組想象成一組特殊的對象。兩者的一個區別便是數組會對數組索引進行特殊的處理。這里所指的數組索引是 ECMAScript 規范中的一個特殊術語。在 JavaScript 中，數組被限制最多只能擁有 2^32-1 項。數組索引是指該限制內的任何有效索引，即從 0 到 2^32-2 的任何整數。

另一個區別是數組還有一個充滿魔力的 length 屬性。

const array = ['a', 'b'];  
array.length; // → 2  
array[2] = 'c';  
array.length; // → 3

在這個例子中，array 在生成時長度單位為 2。接著我們向索引為 2 的位置分配了另一個元素，length 屬性便自動更新。

JavaScript 在定義數組的方式上和對象類似。例如，包括數組索引的所有鍵值都明確地表示為字符串。數組中的***個元素存儲在鍵值為 ‘0’ 的位置下。

'length' 屬性恰好是另一個不可枚舉且不可配置的屬性。

一個元素一旦被添加到數組中，JavaScript 便會自動更新 'length' 屬性的 [[Value]] 屬性值。

一般來說，數組的行為與對象也非常相似。

屬性訪問的優化

讓我們深入了解下 JavaScript 引擎是如何有效地應對對象相關操作的。

觀察 JavaScript 程序，訪問屬性是最常見的一個操作。使得 JavaScript 引擎能夠快速獲取屬性便至關重要。

const object = {  
 foo: 'bar',  
 baz: 'qux',  
};   
 
// Here, we’re accessing the property `foo` on `object`:  
doSomething(object.foo);  
//          ^^^^^^^^^^

Shapes

在 JavaScript 程序中，多個對象具有相同的鍵值屬性是非常常見的。這些對象都具有相同的形狀。

const object1 = { x: 1, y: 2 };  
const object2 = { x: 3, y: 4 };  
// `object1` and `object2` have the same shape.

訪問具有相同形狀對象的相同屬性也很常見：

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

考慮到這一點，JavaScript 引擎可以根據對象的形狀來優化對象的屬性獲取。它是這么實現的。

假設我們有一個具有屬性 x 和 y 的對象，它使用我們前面討論過的字典數據結構：它包含用字符串表示的鍵值，而它們指向各自的屬性值。

如果你訪問某個屬性，例如 object.y，JavaScript 引擎會在 JSObject 中查找鍵值 'y'，然后加載相應的屬性值，***返回 [[Value]]。

但這些屬性值在內存中是如何存儲的呢？我們是否應該將它們存儲為 JSObject 的一部分？假設我們稍后會遇到更多同形狀的對象，那么在 JSObject 自身存儲包含屬性名和屬性值的完整字典便是很浪費（空間）的，因為對具有相同形狀的所有對象我們都重復了一遍屬性名稱。它太冗余且引入了不必要的內存使用。作為優化，引擎將對象的 Shape 分開存儲。

Shape 包含除 [[Value]] 之外的所有屬性名和其余特性。相反，Shape 包含 JSObject 內部值的偏移量，以便 JavaScript 引擎知道去哪查找具體值。每個具有相同形狀的 JSObject 都指向這個 Shape 實例。現在每個 JSObject 只需要存儲對這個對象來說唯一的那些值。

當我們有多個對象時，優勢變得清晰可見。無論有多少個對象，只要它們具有相同的形狀，我們只需要將它們的形狀與鍵值屬性信息存儲一次！

所有的 JavaScript 引擎都使用了形狀作為優化，但稱呼各有不同：

學術論文稱它們為 Hidden Classes（容易與 JavaScript 中的類概念混淆）
V8 將它們稱為 Maps（容易與 JavaScript 中的 Map 概念混淆）
Chakra 將它們稱為 Types（容易與 JavaScript 中的動態類型和關鍵字 typeof 混淆）
JavaScriptCore 稱它們為 Structures
SpiderMonkey 稱他們為 Shapes

本文中，我們會繼續稱它為 shapes。

Transition 鏈與樹

如果你有一個具有特定形狀的對象，但你又向它添加了一個屬性，此時會發生什么？ JavaScript 引擎是如何找到這個新形狀的？

const object = {};  
object.x = 5;  
object.y = 6;

在 JavaScript 引擎中，shapes 的表現形式被稱作 transition 鏈。以下展示一個示例：

該對象在初始化時沒有任何屬性，因此它指向一個空的 shape。下一個語句為該對象添加值為 5 的屬性 “x”，所以 JavaScript 引擎轉向一個包含屬性 “x” 的 Shape，并向 JSObject 的***個偏移量為 0 處添加了一個值 5。接下來一個語句添加了一個屬性 'y'，引擎便轉向另一個包含 'x' 和 'y' 的 Shape，并將值 6 附加到 JSObject（位于偏移量 1 處）。

我們甚至不需要為每個 Shape 存儲完整的屬性表。相反，每個 Shape 只需要知道它引入的新屬性。例如在此例中，我們不必在***一個 Shape 中存儲關于 'x' 的信息，因為它可以在更早的鏈上被找到。要做到這一點，每一個 Shape 都會與其之前的 Shape 相連：

如果你在 JavaScript 代碼中寫到了 o.x，則 JavaScript 引擎會沿著 transition 鏈去查找屬性 “x”，直到找到引入屬性 “x”的 Shape。

但是，如果不能只創建一個 transition 鏈呢？例如，如果你有兩個空對象，并且你為每個對象都添加了一個不同的屬性？

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

在這種情況下我們便必須進行分支操作，此時我們最終會得到一個 transition 樹而不是 transition 鏈：

在這里，我們創建一個空對象 a，然后為它添加一個屬性 'x'。我們最終得到一個包含單個值的 JSObject，以及兩個 Shapes：空 Shape 和僅包含屬性 x 的 Shape。

第二個例子也是從一個空對象 b 開始的，但之后被添加了一個不同的屬性 'y'。我們最終形成兩個 shape 鏈，總共是三個 shape。

這是否意味著我們總是需要從空

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

在***個例子中，我們從空 shape 開始，然后轉向包含 x 的 shape，這正如我們我們之前所見。

在 object2 一例中，直接生成具有屬性 x 的對象是有意義的，而不是從空對象開始然后進行 transition 連接。

包含屬性 'x' 的對象字面量從包含 'x' 的 shape 開始，可以有效地跳過空的 shape。V8 和 SpiderMonkey （至少）正是這么做的。這種優化縮短了 transition 鏈，并使得從字面量構造對象更加高效。

Benedikt 的博文 surprising polymorphism in React applications 討論了這些微妙之處是如何影響實際性能的。

Inline Caches (ICs)

Shapes 背后的主要動機是 Inline Caches 或 ICs 的概念。ICs 是促使 JavaScript 快速運行的關鍵因素！JavaScript 引擎利用 ICs 來記憶去哪里尋找對象屬性的信息，以減少昂貴的查找次數。

這里有一個函數 getX，它接受一個對象并從中取出屬性 x 的值：

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

如果我們在 JSC 中執行這個函數，它會生成如下字節碼：

指令一 get_by_id 從***個參數（arg1）中加載屬性 'x' 值并將其存儲到地址 loc0 中。第二條指令返回我們存儲到 loc0 中的內容。

JSC 還在 get_by_id 指令中嵌入了 Inline Cache，它由兩個未初始化的插槽組成。

現在讓我們假設我們用對象 {x：'a'} 調用 getX 函數。正如我們所知，這個對象有一個包含屬性 'x' 的 Shape，該 Shape 存儲了屬性 x 的偏移量和其他特性。當你***次執行該函數時，get_by_id 指令將查找屬性 'x'，然后發現其值存儲在偏移量 0 處。

嵌入到 get_by_id 指令中的 IC 存儲該屬性的 shape 和偏移量：

對于后續運行，IC 只需要對比 shape，如果它與以前相同，只需從記憶的偏移量處加載該屬性值。具體來說，如果 JavaScript 引擎看到一個對象的 shape 之前被 IC 記錄過，它則不再需要接觸屬性信息——而是完全可以跳過昂貴的屬性信息查找（過程）。這比每次查找屬性要快得多。

高效存儲數組

對于數組來說，存儲屬性諸如數組索引等是非常常見的。這些屬性的值被稱為數組元素。存儲每個數組中的每個數組元素的屬性特性（property attributes）將是一種很浪費的存儲方式。相反，由于數組索引默認屬性是可寫的、可枚舉的并且可以配置的，JavaScript 引擎利用這一點，將數組元素與其他命名屬性分開存儲。

考慮這個數組：

const array = [  
 '#jsconfeu',  
];

引擎存儲了數組長度（1），并指向包含 offset 和 'length' 特性屬性的 Shape。

這與我們之前見過的類似……但數組值存儲在哪里呢？

每個數組都有一個單獨的 elements backing store，其中包含所有數組索引的屬性值。JavaScript 引擎不必為數組元素存儲任何屬性特性，因為它們通常都是可寫的，可枚舉的以及可配置的。

那么如果不是通常的情況呢？如果更改了數組元素的屬性，該怎么辦？

// Please don’t ever do this!  
const array = Object.defineProperty(  
 [],  
 '0',  
 {  
   value: 'Oh noes!!1',  
   writable: false,  
   enumerable: false,  
   configurable: false,  
 }  
);