深入瞭解JavaScript引擎精華

前端之巔2018-06-20 11:56:35

譯者|hijiangtao
編輯|覃雲
本文來自 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。

這是否意味著我們總是需要從空 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 討論了這些微妙之處是如何影響實際性能的。

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,
 }
);

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

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

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

Take-aways

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

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

  • 不要混淆數組元素的屬性特性(property attributes),以確保可以高效地存儲和操作它們。

 相關鏈接

英文原文:

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

知乎譯文:

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

前端之巔

「前端之巔」是 InfoQ 旗下關注大前端技術的垂直社群。緊跟時代潮流,共享一線技術,歡迎關注。


前端之巔

InfoQ大前端技術社群

 活動推薦

GMTC全球大前端技術大會攜手頂級共創夥伴:APICloud企業互聯網化生態平臺,歷時半年籌備,為大家梳理了目前大前端領域的最新動態,並邀請到了來自Google、Twitter、Instagram等國外一線前端專家前來分享他們的前端前沿技術和最佳實踐,更有iOS社區大神Mattt、Apollo GraphQL負責人等大牛的助陣,可謂乾貨滿滿,不容錯過。

目前大會倒計時門票熱銷中,團購更優惠,購票諮詢:18514549229(同微信)戳閱讀原文或識別下圖二維碼,瞭解更多幹貨詳情!


閱讀原文

TAGS: