摘要：解釋器的利弊解釋器啟動和執(zhí)行的更快。正是因為這個原因，解釋器看起來更加適合。這就是為什么最開始的瀏覽器都是用解釋器的原因?？墒钱?dāng)你運行同樣的代碼一次以上的時候，解釋器的弊處就顯現(xiàn)出來了。起初，監(jiān)視器監(jiān)視著所有通過解釋器的代碼。

作者：Lin Clark

編譯：胡子大哈

翻譯原文：http://huziketang.com/blog/posts/detail?postId=58c12f36a6d8a07e449fdd22

英文原文：A crash course in just-in-time (JIT) compilers

轉(zhuǎn)載請注明出處，保留原文鏈接以及作者信息

本文是關(guān)于 WebAssembly 系列的第二篇文章。如果你沒有讀先前文章的話，建議先讀這里。如果對 WebAssembly 沒概念，建議先讀這里（中文文章）。

JavaScript 的啟動比較緩慢，但是通過 JIT 可以使其變快，那么 JIT 是如何起作用的呢？

如果是你一個開發(fā)者，當(dāng)你決定在你的頁面中使用 JavaScript 的時候，有兩個要考慮的事情：目標(biāo)和問題。

目標(biāo)：告訴計算機(jī)你想做什么。

問題：你和計算機(jī)說不同的語言，無法溝通。

你說的是人類的語言，而計算機(jī)用的是機(jī)器語言。機(jī)器語言也是一種語言，只是 JavaScript 或者其他高級編程語言機(jī)器能看得懂，而人類不用他們來交流罷了。它們是基于人類認(rèn)知而設(shè)計出來的。

所以呢，JavaScript 引擎的工作就是把人類的語言轉(zhuǎn)換成機(jī)器能看懂的語言。

這就像電影《降臨》中，人類和外星人的互相交流一樣。

在電影里面，人類和外星人不僅僅是語言不同，兩個群體看待世界的方式都是不一樣的。其實人類和機(jī)器也是類似（后面我會詳細(xì)介紹）。

那么翻譯是如何進(jìn)行的呢？

在代碼的世界中，通常有兩種方式來翻譯機(jī)器語言：解釋器和編譯器。

如果是通過解釋器，翻譯是一行行地邊解釋邊執(zhí)行

編譯器是把源代碼整個編譯成目標(biāo)代碼，執(zhí)行時不再需要編譯器，直接在支持目標(biāo)代碼的平臺上運行。

這兩種翻譯的方式都各有利弊。

解釋器啟動和執(zhí)行的更快。你不需要等待整個編譯過程完成就可以運行你的代碼。從第一行開始翻譯，就可以依次繼續(xù)執(zhí)行了。

正是因為這個原因，解釋器看起來更加適合 JavaScript。對于一個 Web 開發(fā)人員來講，能夠快速執(zhí)行代碼并看到結(jié)果是非常重要的。

這就是為什么最開始的瀏覽器都是用 JavaScript 解釋器的原因。

可是當(dāng)你運行同樣的代碼一次以上的時候，解釋器的弊處就顯現(xiàn)出來了。比如你執(zhí)行一個循環(huán)，那解釋器就不得不一次又一次的進(jìn)行翻譯，這是一種效率低下的表現(xiàn)。

編譯器的問題則恰好相反。

它需要花一些時間對整個源代碼進(jìn)行編譯，然后生成目標(biāo)文件才能在機(jī)器上執(zhí)行。對于有循環(huán)的代碼執(zhí)行的很快，因為它不需要重復(fù)的去翻譯每一次循環(huán)。

另外一個不同是，編譯器可以用更多的時間對代碼進(jìn)行優(yōu)化，以使的代碼執(zhí)行的更快。而解釋器是在 runtime 時進(jìn)行這一步驟的，這就決定了它不可能在翻譯的時候用很多時間進(jìn)行優(yōu)化。

為了解決解釋器的低效問題，后來的瀏覽器把編譯器也引入進(jìn)來，形成混合模式。

不同的瀏覽器實現(xiàn)這一功能的方式不同，不過其基本思想是一致的。在 JavaScript 引擎中增加一個監(jiān)視器（也叫分析器）。監(jiān)視器監(jiān)控著代碼的運行情況，記錄代碼一共運行了多少次、如何運行的等信息。

起初，監(jiān)視器監(jiān)視著所有通過解釋器的代碼。

如果同一行代碼運行了幾次，這個代碼段就被標(biāo)記成了 “warm”，如果運行了很多次，則被標(biāo)記成 “hot”。

如果一段代碼變成了 “warm”，那么 JIT 就把它送到編譯器去編譯，并且把編譯結(jié)果存儲起來。

代碼段的每一行都會被編譯成一個“樁”（stub），同時給這個樁分配一個以“行號 + 變量類型”的索引。如果監(jiān)視器監(jiān)視到了執(zhí)行同樣的代碼和同樣的變量類型，那么就直接把這個已編譯的版本 push 出來給瀏覽器。

通過這樣的做法可以加快執(zhí)行速度，但是正如前面我所說的，編譯器還可以找到更有效地執(zhí)行代碼的方法，也就是做優(yōu)化。

基線編譯器可以做一部分這樣的優(yōu)化（下面我會給出例子），不過基線編譯器優(yōu)化的時間不能太久，因為會使得程序的執(zhí)行在這里 hold 住。

不過如果代碼確實非常 “hot”（也就是說幾乎所有的執(zhí)行時間都耗費在這里），那么花點時間做優(yōu)化也是值得的。

如果一個代碼段變得 “very hot”，監(jiān)視器會把它發(fā)送到優(yōu)化編譯器中。生成一個更快速和高效的代碼版本出來，并且存儲之。

為了生成一個更快速的代碼版本，優(yōu)化編譯器必須做一些假設(shè)。例如，它會假設(shè)由同一個構(gòu)造函數(shù)生成的實例都有相同的形狀——就是說所有的實例都有相同的屬性名，并且都以同樣的順序初始化，那么就可以針對這一模式進(jìn)行優(yōu)化。

整個優(yōu)化器起作用的鏈條是這樣的，監(jiān)視器從他所監(jiān)視代碼的執(zhí)行情況做出自己的判斷，接下來把它所整理的信息傳遞給優(yōu)化器進(jìn)行優(yōu)化。如果某個循環(huán)中先前每次迭代的對象都有相同的形狀，那么就可以認(rèn)為它以后迭代的對象的形狀都是相同的。可是對于 JavaScript 從來就沒有保證這么一說，前 99 個對象保持著形狀，可能第 100 個就少了某個屬性。

正是由于這樣的情況，所以編譯代碼需要在運行之前檢查其假設(shè)是不是合理的。如果合理，那么優(yōu)化的編譯代碼會運行，如果不合理，那么 JIT 會認(rèn)為做了一個錯誤的假設(shè)，并且把優(yōu)化代碼丟掉。

這時（發(fā)生優(yōu)化代碼丟棄的情況）執(zhí)行過程將會回到解釋器或者基線編譯器，這一過程叫做去優(yōu)化。

通常優(yōu)化編譯器會使得代碼變得更快，但是一些情況也會引起一些意想不到的性能問題。如果你的代碼一直陷入優(yōu)化<->去優(yōu)化的怪圈，那么程序執(zhí)行將會變慢，還不如基線編譯器快。

大多數(shù)的瀏覽器都做了限制，當(dāng)優(yōu)化/去優(yōu)化循環(huán)發(fā)生的時候會嘗試跳出這種循環(huán)。比如，如果 JIT 做了 10 次以上的優(yōu)化并且又丟棄的操作，那么就不繼續(xù)嘗試去優(yōu)化這段代碼了樁。

有很多不同類型的優(yōu)化方法，這里我介紹一種，讓大家能夠明白是如何優(yōu)化的。優(yōu)化編譯器最成功一個特點叫做類型特化，下面詳細(xì)解釋。

JavaScript 所使用的動態(tài)類型體系在運行時需要進(jìn)行額外的解釋工作，例如下面代碼：

function arraySum(arr) {
  var sum = 0;
  for (var i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
}

+= 循環(huán)中這一步看起來很簡單，只需要進(jìn)行一步計算，但是恰恰因為是用動態(tài)類型，他所需要的步驟要比你所想象的更復(fù)雜一些。

我們假設(shè) arr 是一個有 100 個整數(shù)的數(shù)組。當(dāng)代碼被標(biāo)記為 “warm” 時，基線編譯器就為函數(shù)中的每一個操作生成一個樁。sum += arr[i] 會有一個相應(yīng)的樁，并且把里面的 += 操作當(dāng)成整數(shù)加法。

但是，sum 和 arr[i] 兩個數(shù)并不保證都是整數(shù)。因為在 JavaScript 中類型都是動態(tài)類型，在接下來的循環(huán)當(dāng)中，arr[i] 很有可能變成了 string 類型。整數(shù)加法和字符串連接是完全不同的兩個操作，會被編譯成不同的機(jī)器碼。

JIT 處理這個問題的方法是編譯多基線樁。如果一個代碼段是單一形態(tài)的（即總是以同一類型被調(diào)用），則只生成一個樁。如果是多形態(tài)的（即調(diào)用的過程中，類型不斷變化），則會為操作所調(diào)用的每一個類型組合生成一個樁。

這就是說 JIT 在選擇一個樁之前，會進(jìn)行多分枝選擇，類似于決策樹，問自己很多問題才會確定最終選擇哪個，見下圖：

正是因為在基線編譯器中每行代碼都有自己的樁，所以 JIT 在每行代碼被執(zhí)行的時候都會檢查數(shù)據(jù)類型。在循環(huán)的每次迭代，JIT 也都會重復(fù)一次分枝選擇。

如果代碼在執(zhí)行的過程中，JIT 不是每次都重復(fù)檢查的話，那么執(zhí)行的還會更快一些，而這就是優(yōu)化編譯器所需要做的工作之一了。

優(yōu)化編譯器中，整個函數(shù)被統(tǒng)一編譯，這樣的話就可以在循環(huán)開始執(zhí)行之前進(jìn)行類型檢查。

一些瀏覽器的 JIT 優(yōu)化更加復(fù)雜。比如在 Firefox 中，給一些數(shù)組設(shè)定了特定的類型，比如里面只包含整型。如果 arr 是這種數(shù)組類型，那么 JIT 就不需要檢查 arr[i] 是不是整型了，這也意味著 JIT 可以在進(jìn)入循環(huán)之前進(jìn)行所有的類型檢查。

簡而言之 JIT 是什么呢？它是使 JavaScript 運行更快的一種手段，通過監(jiān)視代碼的運行狀態(tài)，把 hot 代碼（重復(fù)執(zhí)行多次的代碼）進(jìn)行優(yōu)化。通過這種方式，可以使 JavaScript 應(yīng)用的性能提升很多倍。

為了使執(zhí)行速度變快，JIT 會增加很多多余的開銷，這些開銷包括：

優(yōu)化和去優(yōu)化開銷

監(jiān)視器記錄信息對內(nèi)存的開銷

發(fā)生去優(yōu)化情況時恢復(fù)信息的記錄對內(nèi)存的開銷

對基線版本和優(yōu)化后版本記錄的內(nèi)存開銷

這里還有很大的提升空間：即消除開銷。通過消除開銷使得性能上有進(jìn)一步地提升，這也是 WebAssembly 所要做的事之一。

我最近正在寫一本《React.js 小書》，對 React.js 感興趣的童鞋，歡迎指點。