【Java 虚拟机探索之路系列】：JIT编译器
作者：郭嘉
郵箱：allenwells@163.com
博客：http://blog.csdn.net/allenwells
github：https://github.com/AllenWell
為什么會Java虛擬機會同一時候存在解釋器和編譯器呢？
這是為了兼顧啟動效率和運行效率兩個方面。Java程序最初是通過解釋器進行解釋運行的，當(dāng)虛擬機返現(xiàn)某個方法或代碼塊的運行特別頻繁時，就會把這段代碼標(biāo)記為熱點代碼，為了提供熱點代碼的運行效率，在運行時，虛擬機就會把這些代碼編譯成與本地平臺相關(guān)的機器碼。并進行各種層次的優(yōu)化。
當(dāng)編譯器做的激進優(yōu)化不成立，不如載入了新類后類型繼承結(jié)構(gòu)出現(xiàn)變化。出現(xiàn)了罕見陷阱時能夠進行逆優(yōu)化退回到解釋狀態(tài)繼續(xù)運行。
以上描寫敘述的兩種配合關(guān)系例如以下圖所看到的：
一 編譯模式
HotSpot JVM內(nèi)置了兩個編譯器，各自是Client Complier和Server Complier，虛擬機默認(rèn)是Client模式。我們也能夠通過
- -client：強制虛擬機運行Client模式
- -server：強制虛擬機運行Server模式
而不管是Client模式還是Server模式，虛擬機都會運行在解釋器和編譯器配合使用的混合模式下。能夠通過
- -Xint：強制虛擬機運行于解釋模式
- -Xcomp:強制虛擬機運行于編譯模式
以上描寫敘述的運行模式例如以下圖所看到的：
二 分層編譯
為什么會存在分層編譯？
這是由于編譯器編譯本機代碼須要占用程序運行時間，要編譯出優(yōu)化程度更高的代碼鎖花費的時間可能更長，并且想要編譯出優(yōu)化程度更高的代碼，解釋器可能還要替編譯器收集性能監(jiān)控信息。這對解釋運行的速度也有影響。為了在程序啟動響應(yīng)速度和運行效率之間尋找平衡點。因此採用分層編譯的策略。
分層策略例如以下所看到的：
- 第0層：程序解釋運行。解釋器不開啟性能監(jiān)控功能，可觸發(fā)第1層編譯。
- 第1層：即C1編譯。將字節(jié)碼編譯為本地代碼。進行簡單和可靠的優(yōu)化，如有必要將增加性能監(jiān)控的邏輯。
- 第2層：即C2編譯，將字節(jié)碼編譯為本地代碼，同一時候啟用一些編譯耗時較長的優(yōu)化，甚至?xí)罁?jù)性能監(jiān)控信息進行一些不可靠的激進優(yōu)化。
三 編譯對象
編譯對象即為會被編譯優(yōu)化的熱點代碼。有下面兩類：
- 被多次調(diào)用的方法
- 被多次運行的循環(huán)體
四 觸發(fā)條件
上面描寫敘述中使用多次這個概念，那么什么算多次呢？
這就牽扯到觸發(fā)條件這個概念，推斷一段代碼是否是熱點代碼。是否須要觸發(fā)即時編譯，這樣的行為成為熱點探測（Spot Dectection）。
熱點探測有兩種手段：
4.1 基于採樣的熱點探測（Sample Based Hot Spot Dectection）
虛擬機會周期性的檢查各個線程的棧頂，假設(shè)發(fā)現(xiàn)某些方法常常性的出如今棧頂，那么這種方法就是熱點方法。
4.2 基于計數(shù)器的熱點探測（Counter Based Hot Spot Dectection）
虛擬機會為每一個方法或代碼塊建立計數(shù)器，統(tǒng)計方法的運行次數(shù)。假設(shè)運行次數(shù)超過一定的閾值就覺得他是熱點方法。
HotSpot JVM使用另外一種方法基于計數(shù)器的熱點探測方法。它為每一個方法準(zhǔn)備了兩類計數(shù)器：
4.2.1 方法調(diào)用計數(shù)器
這個閾值在Client模式下是1500次。在Server模式下是10000此，這個閾值能夠通過參數(shù)-XX:CompileThreadhold來人為設(shè)定。
假設(shè)不做不論什么設(shè)置。方法調(diào)用次數(shù)統(tǒng)計的并非方法被調(diào)用的絕對次數(shù)，而是相對的運行頻率，即一段時間內(nèi)方法被調(diào)用的次數(shù)，當(dāng)超過一定時間限度，假設(shè)方法的調(diào)用次數(shù)仍然不足以讓它提交給即時編譯器編譯，那這種方法的調(diào)用計數(shù)器會被降低一半，這個過程被稱為方法調(diào)用計數(shù)器的熱度衰減（Counter Decay）。而這段時間就稱為此方法統(tǒng)計的半衰周期（Counter Half Life Time）。相同也能夠使用參數(shù)-XX:-UseCounterDecay來關(guān)閉熱度衰減。
方法調(diào)用計數(shù)器觸發(fā)即時編譯的整個流程例如以下圖所看到的：
4.2.2 回邊計數(shù)器
什么是回邊？
在字節(jié)碼遇到控制流向后跳轉(zhuǎn)的指令稱為回邊（Back Edge）。
回邊計數(shù)器是用來統(tǒng)計一個方法中循環(huán)體代碼運行的次數(shù)，回邊計數(shù)器的閾值能夠通過參數(shù)-XX：OnStackReplacePercentage來調(diào)整。
- 虛虛擬機運行在Client模式下，回邊計數(shù)器閡值計算公式為：
當(dāng)中OnSlackReplacePercentage默認(rèn)值為933，假設(shè)都取默認(rèn)值.那Client模式虛擬機的回邊計數(shù)器的閡值為13995.
- 虛擬機運行在Servo模式下，回邊計數(shù)器閡值的itm公式為：
當(dāng)中OnStackReplacePementage默認(rèn)值為140. InterpreterPmfilePercenmgc默認(rèn)值為33.
假設(shè)都取默認(rèn)值。BF Server模式虛擬機回邊計數(shù)器的闌值為10700。
回邊計數(shù)器觸發(fā)即時編譯的流程例如以下圖所看到的：
回邊計數(shù)器與方法調(diào)用計數(shù)器不同的是，回邊計數(shù)器沒有熱度衰減，因此這個計數(shù)器統(tǒng)計的就是循環(huán)運行的絕對次數(shù)。
五 編譯流程
在默認(rèn)設(shè)置下，不管是方法調(diào)用產(chǎn)生的即時編譯請求，還是OSR編譯請求，虛擬機在代碼編譯器還未完畢之前，都仍然依照解釋方式繼續(xù)進行，而編譯動作則在后臺的編譯線程中繼續(xù)進行。也能夠使用-XX:-BackgroundCompilation來禁止后臺編譯，則此時一旦遇到JIT編譯，運行線程向虛擬機提交請求后會一直等待，直到編譯完畢后再開始運行編譯器輸出的本地代碼。
那么在后臺編譯過程中，編譯器做了什么事呢？
Server Compiler和Client Compiler的后臺編譯過程是不一樣的，我們來分別看一下。
5.1 Client Compiler編譯流程
整個步驟例如以下圖所看到的：
5.1 Server Compiler編譯流程
Server Compiler是專門面向服務(wù)端的典型應(yīng)用并為服務(wù)器的性能配置特別調(diào)整過的編譯器，它會運行全部經(jīng)典的優(yōu)化動作。例如以下所看到的：
- 無用代碼消除
- 循環(huán)展開
- 循環(huán)表達式外提
- 消除公共子表達式
- 常量傳播
- 基本塊重排序
- 范圍檢查消除
- 空值檢查消除
- 守護內(nèi)聯(lián)
- 分支頻率預(yù)測
轉(zhuǎn)載于:https://www.cnblogs.com/mthoutai/p/7199091.html
總結(jié)
以上是生活随笔為你收集整理的【Java 虚拟机探索之路系列】：JIT编译器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里巴巴为什么主推HSF?比Dubbo有
- 下一篇： Java并发学习之六——等待线程的终结