JavaScript 引擎基礎：Shapes 和 Inline Caches

JavaScript 引擎基礎：Shapes 和 Inline Caches

hijiangtao

​

中國科學院大學 計算機應用技術碩士

260 人贊同了該文章

前言：本文也能夠被稱作 「JavaScript Engines: The Good Parts™」，其來自 Mathias 和 Benedikt 在 JSConf EU 2018 上爲本文主題演講所起的題目，更多 JSconf EU 2018 上有趣的主題分享能夠參考這個答案。

本文就全部 JavaScript 引擎中常見的一些關鍵基礎內容進行了介紹——這不只僅侷限於 V8 引擎。做爲一名 JavaScript 開發者，深刻了解 JavaScript 引擎是如何工做的將有助於你瞭解本身所寫代碼的性能特徵。

譯者注：更多關於 V8 引擎、Chrome 瀏覽器以及 Node 源碼與背後細節的內容，推薦你們能夠關注 

@justjavac

 大大的知乎專欄 V八、Chrome、Node.js 。

回到本文的內容，全文共由五個部分組成：

1. JavaScript 引擎工做流程：介紹 JavaScript 引擎的處理流水線，這一部分會涉及到解釋器／編譯器的內容，且會分點介紹不一樣引擎間的差異與共同點；
2. JavaScript 對象模型；
3. 屬性訪問的優化：經過 Shapes、Transistion 鏈與樹、ICs 等概念的穿插介紹引擎是如何優化獲取對象屬性的；
4. 高效存儲數組；
5. Take-aways：對全文內容作了一個小結，並給了兩點建議。

原文 JavaScript engine fundamentals: Shapes and Inline Caches，做者 @Benedikt 和 @Mathias，譯者 hijiangtao，如下開始正文。

若是你傾向看視頻演講，請移步  YouTube  查看更多。

1. JavaScript 引擎工做流程

這一切都得從你所寫的 JavaScript 代碼開始提及。JavaScript 引擎在解析源碼後將其轉換爲抽象語法樹（AST）。基於 AST，解釋器即可以開始工做併產生字節碼。很是棒！此時引擎正在執行 JavaScript 代碼。

爲了使它執行得更快，能夠將字節碼與分析數據（profiling data）一塊兒發給優化編譯器。優化編譯器根據已有的分析數據作出特定假設，而後生成高度優化的機器碼。

若是在某點上一個假設被證實是不正確的，那麼優化編譯器會去優化並回退至解釋器部分。

1.1 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 引擎都有相同的架構：那就是擁有一個解析器和某種解釋器/編譯器流程。

2. 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]] 屬性值。

通常來講，數組的行爲與對象也很是類似。

3. 屬性訪問的優化

讓咱們深刻了解下 JavaScript 引擎是如何有效地應對對象相關操做的。

觀察 JavaScript 程序，訪問屬性是最多見的一個操做。使得 JavaScript 引擎可以快速獲取屬性便相當重要。

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

3.1 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。

3.2 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。

這是否意味着咱們老是須要從空 shape 開始呢？ 並非。引擎對已包含屬性的對象字面量會應用一些優化。比方說，咱們要麼從空對象字面量開始添加 x 屬性，要麼有一個已經包含屬性 x 的對象字面量：

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 討論了這些微妙之處是如何影響實際性能的。

3.3 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 記錄過，它則再也不須要接觸屬性信息——而是徹底能夠跳過昂貴的屬性信息查找（過程）。這比每次查找屬性要快得多。

4. 高效存儲數組

對於數組來講，存儲屬性諸如數組索引等是很是常見的。這些屬性的值被稱爲數組元素。存儲每一個數組中的每一個數組元素的屬性特性（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, } ); 

上面的代碼片斷定義了一個名爲 '0' 的屬性（這剛好是一個數組索引），但其特性（value）被設置爲了一個非默認值。

在這種邊緣狀況下，JavaScript 引擎會將所有的 elements backing store 表示爲一個由數組下標映射到屬性特性的字典。

即便只有一個數組元素具備非默認屬性，整個數組的 backing store 處理也會進入這種緩慢而低效的模式。 避免在數組索引上使用 Object.defineProperty！ （我不知道爲何你會想這樣作。這看上去彷佛是一個奇怪的且毫無價值的事情。）

5. Take-aways

咱們已經學習了 JavaScript 引擎是如何存儲對象和數組的，以及 Shapes 和 IC 是如何優化針對它們的常見操做的。基於這些知識，咱們肯定了一些有助於提高性能的實用 JavaScript 編碼技巧：

• 始終以相同的方式初始化對象，以確保它們不會走向不一樣的 shape 方向。
• 不要混淆數組元素的屬性特性（property attributes），以確保能夠高效地存儲和操做它們。

（完）

---

我的公衆號 - 微信搜索「黯曉」或掃這個 二維碼

知乎專欄 - 初級前端工程師

生活中不免犯錯，請多多指教！

編輯於 2018-06-18