[[233743]]

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

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

全文共由五個部分組成：

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

2.JavaScript 對象模型；

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

4. 高效存儲數(shù)組；

5.Take-aways：對全文內(nèi)容做了一個小結(jié)，并給了兩點建議。

JavaScript 引擎工作流程

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

為了使它執(zhí)行得更快，可以將字節(jié)碼與分析數(shù)據(jù)（profiling data）一起發(fā)給優(yōu)化編譯器。優(yōu)化編譯器根據(jù)已有的分析數(shù)據(jù)做出特定假設(shè)，然后生成高度優(yōu)化的機器碼。

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

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

現(xiàn)在，讓我們關(guān)注實際執(zhí)行 JavaScript 代碼的這部分流程，即代碼被解釋和優(yōu)化的地方，并討論其在主要的 JavaScript 引擎之間存在的一些差異。

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

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

V8 中的解釋器被稱作 Ignition，它負(fù)責(zé)生成并執(zhí)行字節(jié)碼。當(dāng)它運行字節(jié)碼時會收集分析數(shù)據(jù)，而它之后可以被用于加快（代碼）執(zhí)行的速度。當(dāng)一個函數(shù)變得 hot，例如它經(jīng)常被調(diào)用，生成的字節(jié)碼和分析數(shù)據(jù)則會被傳給 TurboFan——我們的優(yōu)化編譯器，它會依據(jù)分析數(shù)據(jù)生成高度優(yōu)化的機器碼。

 

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

 

Chakra，用于 Edge 和 Node-ChakraCore 兩個項目的微軟 JavaScript 引擎，也有類似兩個優(yōu)化編譯器的設(shè)置。解釋器將代碼優(yōu)化成 SimpleJIT——其中 JIT 代表 Just-In-Time 編譯器——它可以生成部分優(yōu)化的代碼。 結(jié)合分析數(shù)據(jù)，F(xiàn)ullJIT 可以生成更深入優(yōu)化的代碼。

 

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

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

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

JavaScript 對象模型

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

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

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

 

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

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

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

 

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

 

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

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

另一個區(qū)別是數(shù)組還有一個充滿魔力的 length 屬性。

 

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

 

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

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

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

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

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

屬性訪問的優(yōu)化

讓我們深入了解下 JavaScript 引擎是如何有效地應(yīng)對對象相關(guān)操作的。

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

 

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 引擎可以根據(jù)對象的形狀來優(yōu)化對象的屬性獲取。它是這么實現(xiàn)的。

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

 

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

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

 

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

 

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

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

• 學(xué)術(shù)論文稱它們?yōu)?Hidden Classes（容易與 JavaScript 中的類概念混淆）
• V8 將它們稱為 Maps（容易與 JavaScript 中的 Map 概念混淆）
• Chakra 將它們稱為 Types（容易與 JavaScript 中的動態(tài)類型和關(guān)鍵字 typeof 混淆）
• JavaScriptCore 稱它們?yōu)?Structures
• SpiderMonkey 稱他們?yōu)?Shapes

本文中，我們會繼續(xù)稱它為 shapes。

Transition 鏈與樹

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

 

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

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

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

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

 

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

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

 

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

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

Inline Caches (ICs)

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

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

 

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

 

如果我們在 JSC 中執(zhí)行這個函數(shù)，它會生成如下字節(jié)碼：

 

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

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

 

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

 

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

 

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

高效存儲數(shù)組

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

考慮這個數(shù)組：

 

const array = [  
 '#jsconfeu',  
]; 

 

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

 

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

 

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

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

 

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

 

上面的代碼片段定義了一個名為 '0' 的屬性（這恰好是一個數(shù)組索引），但其特性（value）被設(shè)置為了一個非默認(rèn)值。

在這種邊緣情況下，JavaScript 引擎會將全部的 elements backing store 表示為一個由數(shù)組下標(biāo)映射到屬性特性的字典。

 

即使只有一個數(shù)組元素具有非默認(rèn)屬性，整個數(shù)組的 backing store 處理也會進入這種緩慢而低效的模式。 避免在數(shù)組索引上使用 Object.defineProperty！ （我不知道為什么你會想這樣做。這看上去似乎是一個奇怪的且毫無價值的事情。）

Take-aways

我們已經(jīng)學(xué)習(xí)了 JavaScript 引擎是如何存儲對象和數(shù)組的，以及 Shapes 和 IC 是如何優(yōu)化針對它們的常見操作的?；谶@些知識，我們確定了一些有助于提升性能的實用 JavaScript 編碼技巧：

始終以相同的方式初始化對象，以確保它們不會走向不同的 shape 方向。

不要混淆數(shù)組元素的屬性特性（property attributes），以確?？梢愿咝У卮鎯筒僮魉鼈?。

相關(guān)鏈接

英文原文：

https://mathiasbynens.be/notes/shapes-ics

知乎譯文：

https://zhuanlan.zhihu.com/p/38202123