3　JavaScriptCore引擎

3.1　原理

????????JavaScriptCore引擎是WebKit中的默認(rèn)JavaScript引擎，也是蘋果在開源WebKit項目之后，開源的另外一個重要的項目。同其他很多引擎一樣，在剛開始的時候它的主要部分是一個基于抽象語法樹的解釋器，這使得它的性能實在太差。

????????從2008年開始，JavaScriptCore引擎開始一個新的優(yōu)化工作，重新實現(xiàn)了編譯器和字節(jié)碼解釋器，這就是SquirrelFish。該工作對于引擎的性能優(yōu)化做了比較大的改進。隨后，蘋果內(nèi)部代號為“Nitro”的JavaScript引擎也是基于JavaScriptCore項目的，它的性能還是非常出色的，鑒于其是內(nèi)部項目，所以具體還有什么特別的處理就不得而知了。在這之后，開發(fā)者們又將內(nèi)嵌緩存、基于正則表達式的JIT和簡單的JIT引入到JavaScriptCore中。然后，又陸續(xù)加入了字節(jié)碼解釋器?？梢钥闯?#xff0c;JavaScriptCore引擎也在不斷地高速發(fā)展中。

3.2　架構(gòu)和模塊

3.2.1　代碼結(jié)構(gòu)

????????根據(jù)JavaScriptCore項目的代碼結(jié)構(gòu)和之前介紹的引擎的工作過程，讀者大概可以猜測出代碼結(jié)構(gòu)中到底有哪些主要模塊和基本的工作了，因為該結(jié)構(gòu)劃分的粒度比V8項目細致多了，還是比較容易理解的，如圖9-20所示的代碼結(jié)構(gòu)目錄。

????????

????????????????????????????????圖9-20　JavaScriptCore代碼結(jié)構(gòu)

????????從代碼目錄中，我們可以猜測并理解它的演進過程：首先是詞法和語法分析，然后使用底層解釋器來解釋那些字節(jié)碼。之后，通過簡單的JIT編譯器將它們轉(zhuǎn)化成本地代碼。還沒結(jié)束，最后就是引入DFG JIT編譯器。

????????這些目錄直接跟即將介紹的各個技術(shù)有很好的對應(yīng)關(guān)系，讀者先有個大致的理解，這樣對后面的介紹大有幫助，感興趣的讀者還可以去查找源碼來有個基本的認(rèn)識。

3.2.2　數(shù)據(jù)表示

????????JavaScriptCore引擎同樣使用句柄來表示數(shù)據(jù)，對于簡單類型的數(shù)據(jù)則直接包含在句柄中，而對于對象來說，則使用指針來指向數(shù)據(jù)在堆中的位置。同V8引擎不同的是，在32位和64位機器上，句柄都是使用64位來表示的，圖9-21分別描述了兩種平臺上各種類型的表示和識別方式。

????????????????????????????????圖9-21　句柄的定義和各種類型的表示方式

????????首先在32位平臺上，每個句柄都是使用兩個32位數(shù)據(jù)來表示。對于整數(shù)、布爾和指針而言，前面32位用來標(biāo)記它們，后面32位用來表示這些數(shù)據(jù)。對于雙浮點，前32位在區(qū)間FFFFFFF8~00000000都是用來表示浮點類型，可能稍微比原來的雙浮點表示范圍小一些，但是，這個范圍已經(jīng)足夠使用了。同樣在64位機器上，因為標(biāo)記指針需要64位，只好使用前面16位（0000），而后面的48位用來表示地址，讀者可能覺得這樣就沒有64位表示指針，但是實際上48位已經(jīng)足夠。

????????同V8引擎相比，JavaScriptCore引擎因為在32位上使用64位來表示句柄，所以除了小整數(shù)之外，對于浮點類型同樣可以不需要訪問堆中的數(shù)據(jù)，當(dāng)然，缺點就是每個句柄都需要2倍的內(nèi)存空間。

3.2.3　模塊

????????同V8一樣的是，JavaScriptCore引擎在開源之后也引入了眾多新技術(shù)。不過，JavaScriptCore引擎與V8相比還是有很多不同之處的，最典型的就是它使用了字節(jié)碼的中間表示，并加入了多層JIT編譯器幫助改善性能，不停地優(yōu)化編譯之后的本地代碼。當(dāng)然JavaScriptCore在不停地演進的過程中，目前的實現(xiàn)跟之前的實現(xiàn)差別非常大，所以這里介紹的是基于目前的結(jié)構(gòu)的，在未來，可能還會有很多其他的變化，讓我們拭目以待。

????????第一，不同于V8引擎，JavaScriptCore引擎不是從抽象語法樹生成本地代碼，而是生成平臺無關(guān)的字節(jié)碼，如圖9-22所示。JavaScriptCore引擎自己定義了一套字節(jié)碼規(guī)范，該字節(jié)碼與平臺無關(guān)，而且有了該字節(jié)碼，JavaScriptCore就可以基于其進行很多在抽象語法樹之上不能或者很難做到的優(yōu)化。讀者需要記住的是，不同于V8，在這之后，因為有了字節(jié)碼，所以JavaScriptCore就不再需要JavaScript源代碼，而V8使用Crankshaft編譯器進行進一步優(yōu)化，則需要繼續(xù)從JavaScript源代碼重新開始。

????????????????????????????????圖9-22　JavaScriptCore中從源代碼到字節(jié)碼

????????第二，在字節(jié)碼之后，JavaScriptCore依然包含了字節(jié)碼解釋器，這點也類似于Java虛擬機中的解釋器，它們都能夠解釋字節(jié)碼然后生成結(jié)果。而不同于Java虛擬機中的解釋器的是，JavaScriptCore是基于虛擬寄存器（Virtual Register）的虛擬機，而Java是基于棧式（Stack）的虛擬機。這一解釋器很有必要，因為一些JavaScript代碼不需要經(jīng)過很強的優(yōu)化，只需要直接執(zhí)行即可，復(fù)雜的處理可能帶來額外開銷反而抵消了優(yōu)化帶來的全部好處，如圖9-23所示。同時，在字節(jié)碼執(zhí)行期間，信息收集器會收集熱點函數(shù)，以方便之后的JIT編譯器做之后的優(yōu)化處理。圖中的信息收集器1之所以加上“1”，是為了區(qū)別JavaScriptCore中包含的各種各樣的信息收集器。

????????????????圖9-23　JavaScriptCore從字節(jié)碼到解釋器和信息收集器

?????????第三，JavaScriptCore引擎在獲悉熱點函數(shù)后，需要對它們進行優(yōu)化，就會使用到簡單（Baseline）JIT編譯器，該編譯器根據(jù)信息收集器1中的信息，將對應(yīng)函數(shù)的字節(jié)碼翻譯成本地代碼，不僅因為時間問題，而且并不是所有代碼都合適做深層次的優(yōu)化，所以這里沒有做特別多的優(yōu)化，而是直接做轉(zhuǎn)換。圖9-24描述了這一過程。在實行這些本地代碼的時候，會有信息收集器2來收集代碼并作做一步的優(yōu)化。

????????????????圖9-24　JavaScriptCore的簡單JIT編譯器

????????第四，如果你認(rèn)為只需要JIT編譯器就夠了，那就錯了，簡單的JIT編譯器并不能滿足性能的要求，特別是對V8的Crankshaft編譯器來說，性能差距就顯現(xiàn)出來了。為了提高性能，JavaScriptCore中又引入了DFG（Data-Flow Graph）JIT編譯器，該編譯器是在字節(jié)碼基礎(chǔ)上，生成基于SSA（Static Single Assignment）的中間表示（IR）。當(dāng)然具體哪些字節(jié)碼需要重新生成優(yōu)化的本地代碼，就依賴之前的信息收集器2，如圖9-25所示。優(yōu)化后的本地代碼相比之前的代碼，對于性能有很好的提升。

????????????????????????????????圖9-25　JavaScriptCore的DFG JIT編譯器

????????第五，要是你認(rèn)為這樣就足夠了，那就更錯了。在筆者介紹JavaScriptCore的時候，該項目依然在進行一項更為大膽的工作，就是將LLVM技術(shù)引入到JavaScriptCore。那么LLVM是什么呢？LLVM是一個由蘋果公司發(fā)起的開源項目，其開發(fā)和靈活的架構(gòu)受到越來越多人的關(guān)注。

????????LLVM是一個編譯器，能夠?qū)⒍鄠€不同的前端語言轉(zhuǎn)化成不同的后端本地代碼，圖9-26描述了LLVM的基本結(jié)構(gòu)，該編譯器在前端和后端都能做優(yōu)化，這些優(yōu)化都是可配置的，所以非常靈活。同時，隨著該項目越來越成功，加入的優(yōu)化也越來越多。JavaScriptCore希望將LLVM編譯器的中間表示引入其中，這樣將很容易將這些優(yōu)化使用在該引擎中，圖9-27描述了這一過程。

????????????????????????????????????????圖9-26　LLVM基本結(jié)構(gòu)

????????????????????????????????????????圖9-27　使用LLVM技術(shù)的JIT編譯器

????????這一過程是基于DFG JIT中間表示開始的，為了節(jié)省時間，使用了并行編譯算法。之后，生成LLVM的中間表示，這樣就可以使用LLVM中間表示之后的眾多優(yōu)化，而且可以按需配置它們。這一過程僅僅對于那些最熱點的函數(shù)使用，因為其層次太多，消耗的時間更多，所以慎用。這一技術(shù)目前還在開發(fā)中，未來效果如何還未可知，不過相信對于某些特定的例子會有不少好處。

? ? ? ? 為什么不直接使用優(yōu)化性能最好的編譯器呢？原因是優(yōu)化越好通常需要的分析和生成代碼的時間就越長。讀者回憶之前介紹的應(yīng)用場景就會發(fā)現(xiàn)，如果用戶使用的是利用C/C++編譯的代碼，那么編譯時間長一點問題不大，因為是開發(fā)者在編譯他們。而對于JavaScript來說，編譯時間越長，對用戶來說同樣，等待的時間更長，效果可能也未必會好。這就是一把雙刃劍，所以該方法只限定在特定的范圍內(nèi)使用。

3.4　內(nèi)存管理

????????在JavaScriptCore中，內(nèi)存管理和垃圾回收機制也隨著其他技術(shù)的改變而發(fā)生著很大的變化。對于垃圾回收機制來說，最重大的改變就是像V8一樣，引入了分代垃圾回收機制。所以，堆也會被分成幾個分代。這樣，當(dāng)進行垃圾回收的時候，就不需要對所有對象進行標(biāo)記。分代技術(shù)前面也討論過了，而且很早就在其他虛擬機中使用，如Java虛擬機，它們思想都是類似的，這里不再贅述。

?????????在V8中使用Zone來一次性釋放內(nèi)存，JavaScriptCore中也有類似的機制，那就是JSGlobalData，這里也不再過多的描述。

3.5　綁定

????????JavaScriptCore同樣能夠提供綁定機制，目前渲染引擎同樣是通過該機制訪問DOM的操作函數(shù)，這點跟V8非常像。本質(zhì)上，它們都是提供額外的JavaScript接口來擴展JavaScript引擎的能力。同樣，我們將在下一章做詳細介紹。

3.6　比較JavaScriptCore和V8

????????由于JavaScriptCore一直是Webkit的默認(rèn)JavaScript引擎，所以被廣泛應(yīng)用。但是，隨著Google發(fā)布Chrome的同時加上V8引擎，而且V8自出現(xiàn)后就是以性能作為目標(biāo)，引入了眾多新穎的技術(shù)，確實極大地推動了整個業(yè)界的JavaScript引擎性能的快速發(fā)展。但是，如果想用一句話說明V8和JavaScriptCore的優(yōu)劣，這是很困難的。在很多領(lǐng)域，V8扮演著沖鋒者的角色，但是JavaScriptCore依舊不斷改進自己的技術(shù)和實現(xiàn)，同時在某些方面，因為使用了一些V8沒有的東西，如字節(jié)碼反而在某些情況下較容易優(yōu)化。當(dāng)然，這也不是絕對的。

????????關(guān)于各個技術(shù)細節(jié)，例如內(nèi)部代碼表示、解釋器、JIT、句柄數(shù)據(jù)表示等方面，我們在前面都一一做了介紹，讀者可以回憶一番。我們前面已經(jīng)介紹了以上兩個引擎的很多特點和好處，筆者還希望留一些想象的空間，讓讀者自己體會上面這些技術(shù)細節(jié)帶來的潛在優(yōu)勢和缺點，以及潛在的發(fā)展方向。