JavaScript引擎基本原理: 優化prototypes

原文連接: JavaScript engine fundamentals: optimizing prototypes

這篇文章介紹了一些JavaScript引擎經常使用的優化關鍵點, 並不僅是Benedikt和Mathias開發的v8. 做爲一名js開發者, 更深層次的瞭解引擎的工做原理能夠幫助你瞭解你代碼的性能特徵.

以前, 咱們js使用shapes和inline caches優化對象和數組的訪問. 這篇文章介紹了優化管道的權衡利弊(trade-off, 就是前面的使用解析器和優化器的權衡), 以及介紹了引擎如何提高訪問原型的性能.

優化層(tiers)和權衡利弊(trade-off)的執行

咱們上一篇文章介紹瞭如今JavaScript引擎都擁有的相同的管道(pipeline):

咱們也指出, 即便在引擎之間的高程度管道如此相似, 可是在優化管道的時候, 仍是會有一些不一樣. 那是什麼緣由呢? 爲何一些引擎能夠作到比其餘引擎更高程度的優化層呢? 那就致使了權衡利弊這種結果, 是選擇更快的產生代碼去運行, 仍是花費更多的時間在最後運行優化程度更高的代碼.

解析器能夠更快的產生機器碼, 可是這些機器碼一般並不高效. 優化器使用另外一種方式多花費一點時間能夠產生更加高效的機器碼.

事實上這就是V8所使用的模型. V8中的解析器被稱爲啓動器(ignition), 單就原始代碼的執行速度而言, v8的解釋器(ignition)是最快的. V8的優化器叫作(TurboFan), 最後能夠產生優化程度更高的機器碼.

啓動延遲和執行速度之間的權衡, 致使了一些引擎選擇在他們中間添加一個優化層. 舉個例子: SpiderMonkey添加了一個 基線 (BaseLine) 在解釋器和他的整個IconMonkey優化器之間.

解釋器能夠更快的產生字節碼, 可是字節碼的執行相對較慢. 基線 可使用多一點時間產生代碼, 可是能夠提供更好的運行時間優化. 最後, IonMonkey優化器花費更長的時間產生的機器碼, 這些代碼能夠運行的更加高效.

讓咱們從一個具體的例子看下不一樣引擎下的管道(pipeline)如何使用它. 下面是一段在熱循環中重複獲取的代碼.

let result = 0;
for (let i = 0; i < 4242424242; i++) {
  result += i;
}
console.log(result);

v8開始使用Ignition解釋器運行代碼. 引擎經過一些細節肯定這段代碼是 熱(hot) 的, 開始啓動TurboFan frontend, 這是TurboFan的一部分. 用來處理收集的數據, 生成一個基礎的機器代碼的表示. 這些東西經過不一樣的線程發送給TurboFan優化器, 用於之後的性能提高.

當優化器開始執行的時候, v8依舊使用ignition運行字節碼. 當一些優化完成的時候, 咱們得到更高執行效率的機器碼, 而後接下來就是使用這些機器碼進行運行.

SpiderMonkey開始也是使用解釋器運行代碼. 可是他在中間已經添加了基線層, 這表示熱代碼(hot code)在第一時間發送給基線層. 基線層優化器在主線程上產生基線代碼, 並在準備就緒後執行代碼.

當代碼運行一會的時候, SpiderMonkey啓動Ionmonkey fronted, 和開始優化, 這和V8很是類似. 可以在IconMonkey開始優化的時候, 繼續在Baseline上運行. 最後, 當優化結束, 優化後的代碼代替基線代碼開始執行.

Chakra的體系結構和SpiderMonkey很是類似, 可是Chakra爲了不主線程阻塞會嘗試運行更多的某些東西. 爲了替代編譯器運行在主線程的全部部分, Chaka會把全部編譯器看起來像是須要的字節碼和分析數據複製出來, 併發送他們給優化器, 用來決定優化過程.

一旦代碼產生完成, 引擎就開始運行SimpleJIT的代碼. 相同的方式啓動FullJIT. 這種方式的好處是: 複製所須要的時間遠遠低於一個完整的優化器(fronted)運行運行. 可是這種方式的缺點是, 啓發式的複製(copy heuristic) 會失去一些須要當前優化方式的信息, 因此沒能保證代碼質量會形成某種程度的延遲.

在JavaScriptCor引擎中, 全部的優化編譯器都會和JavaScript主線程一塊兒 徹底同步 執行. 那裏並無複製的部分. 相反, 主線程僅僅是觸發在另外一個線程上的編譯工做, 也就是優化工做. 這些優化器會使用複雜的鎖定方案訪問主線程上的分析數據.

這種方案優勢是減小了JavaScript優化器在主線程上的閃避(jank). 負面影響是須要處理複雜的多線程問題, 而且須要爲各類操做付出鎖的消耗.

咱們討論了關於在解釋器上更快的產生代碼和在解釋器上更快的產生代碼. 可是還有一種權衡: 內存佔用! 爲了說明這個問題, 下面是求兩數加和的簡單的JavaScript程序.

function add(x, y) {
  return x + y;
}
add(1, 2)

下面是咱們使用V8引擎中的ignition解釋器, 對add函數產生的字節碼.

StackCheck
Ldar a1
Add a0, [0]
Return

不要擔憂這些真實的字節碼, 你並不須要真會認識他們. 須要強調的點是只有四個表示

當代碼變熱的時候, TurboFan會產生下面這種更高程度優化的機器碼.

leaq rcx,[rip+0x0]
movq rcx,[rcx-0x37]
testb [rcx+0xf],0x1
jnz CompileLazyDeoptimizedCode
push rbp
movq rbp,rsp
push rsi
push rdi
cmpq rsp,[r13+0xe88]
jna StackOverflow
movq rax,[rbp+0x18]
test al,0x1
jnz Deoptimize
movq rbx,[rbp+0x10]
testb rbx,0x1
jnz Deoptimize
movq rdx,rbx
shrq rdx, 32
movq rcx,rax
shrq rcx, 32
addl rdx,rcx
jo Deoptimize
shlq rdx, 32
movq rax,rdx
movq rsp,rbp
pop rbp
ret 0x18

這裏有 很是 多的代碼, 尤爲是當咱們和字節碼中四個表示符相比的時候. 和機器碼相比, 字節碼變得更加緊湊, 尤爲是和優化事後的機器碼相比. 但從另外一個方面來講, 字節碼須要一個解釋器進行運行, 可是優化事後的代碼能夠經過處理器直接執行.

這就是JavaScript引擎不去優化一切的主要緣由之一. 剛剛咱們看到的, 產生優化後的機器碼須要更長的時間, 除此以外, 還有咱們剛剛學到的優化後的機器碼也須要更高的內存空間

摘要: JavaScript引擎有不一樣的優化層的緣由: 對於解釋器更快的產生字節碼, 和優化器更加快速的產生代碼的權衡. 這是一個策略, 你是否願意付出更大的複雜度和開支, 來添加更多的優化層, 來獲取更加精細的決策. 總結, 這是關於產生代碼過程當中優化程度, 和內存使用的權衡. 這就是JavaScript引擎只優化hot函數的緣由.

優化原型屬性訪問

上一篇文章中介紹到: JavaScript引擎如何經過引入Shapes和Inline Caches來優化對象屬性. 回顧下: 引擎將對象的Shape和對象的值分開存儲.

Shapes 支持一種被稱爲 Inline Caches 或者 ICs 的優化. 結合起來, Shapes和ICs可以提高你代碼中相同地方, 重複訪問的屬性.

類和基於原型的編程(Classes and prototype-based programming)

如今咱們知道如何更加快速的訪問JavaScript對象上的屬性, 讓咱們來看下最近JavaScript中新增的: classess. 下面是這種JavaScript類語法的表示形式:

class Bar {
  constructor(x) {
    this.x = x;
  }
  getX() {
    return this.x;
  }
}

儘管這是在JavaScript中新出現的一一種概念, 但他也不過是以前JavaScript關於原型編程的語法糖:

function Bar(x) {
  this.x = x;
}
Bar.prototype.getX = function getX() {
  return this.x;
}

在這, 咱們分配了一個getX屬性到Bar.prototype對象上. 他的實際的工做方式和其餘的對象是同樣的, 由於在JavaScript中原型就是一個對象! JavaScript語言更像是一門基於原型編程的語言, 經過原型分享方法的使用, 字段(也就是那些值)實際存儲在真實的實例上.

讓咱們仔細觀察下, 當經過Bar的執行建立一個新的foo實例的時候, 所發生的一切.

const foo = new Bar(true)

運行這段代碼能夠產生一個實例對象, 這個實例對象有一個模型, 這個模型上面只有一個屬性x. Bar.prototype屬於類Bar, 上面擁有屬性foo

這個Bar.prototype也擁有它本身的模型, 包含了惟一的屬性getX, 它的值對應了咱們的函數getX, 就是執行的時候, 返回this.x的函數. Bar.prototype的原型就是Object.prototype, 這是JavaScript語言的一部分. Object.prototype就是原型鏈的根節點, 而後他的原型指向null.

當咱們使用這個相同的類建立另外一個實例的時候, 兩個實例會共享一個對象模型, 就像咱們前面討論的那樣. 兩個實例的指針都指向同一個相同的Bar.prototype對象.

Prototype property access

好了, 如今咱們知道了當咱們定義一個類和建立一個實例的時候發生了什麼. 可是, 若是咱們運行一個實例上的方法會發生什麼呢? 就像下面這樣.

class Bar {
  constructor(x) {
    this.x = x;
  }
  getX() {
    return this.x;
  }
}
const foo = new Bar(true);
const x = foo.getX();
//            ^^^^^

你能夠理解爲任何方法的執行都做爲兩個步驟.

const x = foo.getX();

// 實際通過了兩個步驟
const $getX = foo.getX;
const x = $getX.call(foo)

第一步的時候, 加載這個函數, 那只是原型上的一個屬性, 他的值偏偏是一個函數.第二步的時候, 使用實例上做爲this運行這個值. 讓咱們完成從實例foo上加載函數getX的第一步.

引擎先從foo實例開始尋找, 發如今foo模型上沒有getX屬性, 而後就會沿着原型鏈一直尋找. 當咱們找到Bar.prototype, 獲取了他的原型的模型, 發現了getX屬性, 而且存儲了偏移量0. 咱們在Bar.prototype上發現getX是一個JSFunction. 那就是他了.

JavaScript的靈活性, 可能讓他們的原型鏈忽然發生變化. 例如:

const foo = new Bar(true);
foo.getX();
// -> true

Object.setPrototypeOf(foo, null);
foo.getX();
// -> Uncaught TypeError: foo.getX is not a function

在這個例子中, 咱們兩次與運行foof.getX(), 可是每一次執行都有徹底不一樣意義和結果. 這就是爲何, 即便原型在JavaScript僅僅是一個對象, 提升原型上屬性的訪問速度比僅僅提升在常規對象上面普通屬性的訪問, 要更有挑戰性.

下面這個程序, 可以發現, 加載原型屬性是很是頻繁的操做: 你每一次執行函數的時候都會發生.

class Bar{
  constructor(x) {
    this.x = x;
  }
  getX() {
    return this.x;
  }
}
const foo = new Bar(true);
const x = foo.getX;
//        ^^^^^^^^

以前, 咱們討論了若是進行常規屬性的加載優化, 即是經過使用Shapes和ICs. 那麼咱們應該如如優化具備相關模型的原型屬性的的重複訪問呢? 咱們看下面的屬性訪問若是工做.

爲了在某些特定的案例中保證對重複屬性訪問的最快速度, 咱們須要肯定如下三點.

1. foo的模型肯定不含有getX, 而且模型不會改變. 這表示, 沒有任何對於foo對象的添加或者刪除屬性的操做, 也不會對現有屬性描述進行改變.
2. foo的原型依舊是最初的Bar.prototype. 這表示foo的原型不會經過Object.setPrototypeOf()或者直接訪問特殊的__proto__進行改變.
3. Bar.prototype上的模型, 包含getX而且不會改變. 也就表示, 不會對Bar.prototype進行任何添加或者刪除屬性, 或缺對屬性描述進行修改.

在這個例子中, 咱們須要對原型自己進行一次檢查, 而後須要對原型上的每個原型進行兩次檢查, 一直找到包含咱們須要屬性的原(我不明白這裏爲何須要檢查兩次).1+2N次查找(N表示表示原型的複雜程度, (是指原型鏈的長度, 仍是原型上註冊的屬性個數))在咱們的案例中聽起來沒這麼糟糕, 由於整個原型鏈相對短一些. 可是引擎常常會處理一些相對較長的原型鏈, 就想在一個普通的DOM案例中. 下面是例子:

const anchor = document.createElement('a');
// -> HTMLAnchorElement

const title = anchor.getAttribute('title');

咱們有了一個HTMLAnchorElement, 而後咱們執行了元素上的getAttrubute()方法. 這個簡單的錨點元素的原型鏈, 已經存在6層原型長度. 大部分使用的DOM方法不會在在HTMLAnchorelElment原型上直接註冊, 可是在更高程度的原型鏈上.

只有在Element.prototype上面才能夠發現方法getAttribute()方法. 那就意味着, 咱們每次調用anchor.getAttribute(), JavaScript引擎都須要作一下工做:

1. 檢查getAttribute是否存在於anthor對象自己.
2. 檢查HTMLAnchorElement.prototype這個原型對象.
3. 確認getAttribute屬性不在上面.
4. 檢查下一個原型:HTMLElement.prototype
5. 確認getAttribute屬性也不在這.
6. 終於檢查到了下一個原型Element.prototype
7. 發現了getAttribute屬性

一共是七次查找. 由於在web中, 這種代碼很是常見. 引擎應用一些技巧減小原型屬性訪問的檢查次數, 是很關鍵的.

退回上一個例子, 當咱們訪問foo上面的getX屬性的時候, 一共通過了三次查找.

class Bar {
  constructor(x) {
    this.x = x;
  }
  getX() {
    return this.x;
  }
}

const foo = new Bar(true);
const $getX = foo.getX;

對於每一個涉及的對象的模型, 咱們都須要作屬性檢查, 直接找到攜帶屬性的那個. 若是咱們可以經過摺疊屬性檢查變成缺乏檢查, 來檢查屬性檢查, 就太好了. 而且這是引擎應用的很是重要的小技巧: 引擎存儲在實例自己上的原型鏈替換爲存儲在Shape上.

每個模型都指向了原型. 這也意味着每一次foo原型改變的時候, 引擎都會轉變成一個新的模型. 如今咱們只須要去檢查一個對象的模型, 便可以判斷是否含有目標屬性, 又能夠保護原型鏈.

經過這個方法, 咱們加快原型屬性的訪問, 從1+2N變爲1+N. 可是那已經具備很是大的消耗, 由於依舊和原型鏈的長度線性相關. 引擎應用不一樣的技巧減小之後檢查的次數, 尤爲是後面關於相同屬性加載的訪問執行.

Validity cells

基於這個目的, V8特地處理的模型的形狀. 每個原型都有與其餘對象不共享的模型 尤爲是其餘的原型對象. 而且這些原型模型, 都會有一個特殊的ValidityCell與他關聯.

不管是任何關聯原型的改變, 或者是原型上屬性的改變, 這個ValidityCell都會失效. 讓咱們看下他實際如何工做.

爲了提升後面屬性的加載, V8會在內存中安置一個具備四個屬性的在線緩存.

當咱們第一次運行這段代碼的時候, 進行預熱處理, V8記錄了咱們發現原型上屬性的偏移量, 含有這個屬性的原型(在這個例子中就是Bar.prototype), 實例的模型(這個例子中是foo的模型), 而後也會有一條線指向當前的ValidityCell, 也就是 當即原型(immediate prototype) 那是一條來自實例原型的線(在這個例子中也是發生在Bar.prototype).

下一次執行的時候, 這個內嵌緩存就被打開了, 引擎會去查找實例模型, 和ValidityCell. 當他是有效的時候, 引擎能夠理解查找出Prototype上的Offset, 再也不進行額外的查找.

當原型改變的時候, 給原型分配一個小的模型, 上一個ValidityCell失效. 致使在線緩存在下一次執行的時候關掉, 影響性能.

讓咱們退回到以前的DOM元素的例子, 他意味着, 在Object.prototype上的任何改變, 都不僅是讓他本身的內嵌緩存失效, 可是也讓他下面的原型, 包括EventTarget.prototype, Node.prototype, Element.prototype等等, 一直到HTMLAnchorElement.prototype的路都垮掉了.

實際上, 在代碼中修改Object.prototype表示再無性能可言. 千萬不要這麼作.

讓咱們經過一個具體的例子探索更多. 看的出, 咱們有一個類Bar, 而且咱們有一個函數loadX, 經過Bar對象執行. 咱們只是在剛剛經過一個來自相同類的實例, 執行了loadX這個函數.

class Bar { /* ... */ }
function loadX(bar) {
  return bar.getX(); // IC for 'getX' on `Bar` instance
}

loadX(new Bar(true));
loadX(new Bar(false));
// IC in 'loadX' now links the `ValidityCell` for `Bar.prototype`

Object.prototype.newMethod = y => y;
// The `ValidityCell` in the `loadX` IC is invalid now, because `Object.prototype` changed

在loadX上的內嵌緩存指向了Bar.prototype的ValidityCell. 若是你隨後作了一些操做, 例如忽然改變了Object.prototype, 這是JavaScript中全部原型的根節點, ValidityCell都會變得無效, 而且全部的在線緩存在下一次更改的時候, 都會關閉, 致使性能變得不好.

讓Object.prototype忽然改變是很是糟糕的方法, 由於他可讓全部在此操做以前引擎放置的, 關於原型加載的內嵌緩存都失效. 下面是兩一個不要作的例子:

Object.prototype.foo = function() {
  /* ... */
};

// Run critical code
someObject.foo();
// End of critical code

delete Obejct.prototype.foo;

咱們擴展了Object.prototype, 那會讓引擎以前放置的在線緩存失效. 而後咱們使用這個新原型方法運行了一些代碼. 整個引擎必須從新開始, 當我歐恩訪問原型屬性的時候, 設置新的屬性緩存. 在最後, 咱們本身"清除了本身", 而後移除了咱們最近添加的原型方法.

清除也許聽起來是一個好主意, 真的嗎? 哇, 在這個案例中, 他達到了最壞的後果. 修改Object.prototype刪除上的屬性, 會讓全部的IC再次所有失效, 引擎又要從新開始.

提示: 儘管, 原型只是一個對象, 可是他們已經經過JavaScript引擎特殊處理, 優化了再原型上查找方法的性能. 讓你的原型保持孤獨. 或者, 當你須要去移動原型的時候, 那就再全部的代碼以前操做, 保證你最後一次操做, 並不讓引擎針對你代碼的優化失效.

另外

咱們學習了JavaScript引擎如何存儲對象和類, Shpaes, 內嵌緩存, 和ValidityCell若是幫助咱們優化原型操做. 基於這些知識, 咱們發現了一個使用的JavaScript編碼優化技巧, 不要亂搞原型, (或者 你真的真的須要這麼作的話, 在全部代碼運行執行處理他.)