3　JavaScriptCore引擎

3.1　原理

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

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

3.2　架構(gòu)和模塊

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

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

????????

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

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

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

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

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

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

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

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

3.2.3　模塊

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

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

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

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

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

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

????????????????圖9-24　JavaScriptCore的簡(jiǎn)單JIT編譯器

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

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

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

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

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

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

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

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

3.4　內(nèi)存管理

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

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

3.5　綁定

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

3.6　比較JavaScriptCore和V8

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

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