解釋器

當虛擬機啟動時，解釋器可以首先發(fā)揮作用，而不必等待編譯器全部編譯完成再執(zhí)行，這樣可以省去許多不必要的編譯時間。并且隨著程序運行時間的推移，編譯器逐漸發(fā)揮作用，根據(jù)熱點探測功能，，將有價值的字節(jié)碼編譯為本地機器指令，以換取更高的程序執(zhí)行效率。

hotspot中內(nèi)嵌有2個JIT編譯器，分別為Client Compiler，Server Compiler，但大多數(shù)情況下我們稱之為C1編譯器和C2編譯器。

C1編譯器

client compiler，又稱C1編譯器，較為輕量，只做少量性能開銷比較高的優(yōu)化，它占用內(nèi)存較少，適合于桌面交互式應用。在寄存器分配策略上，JDK6以后采用的為線性掃描寄存器分配算法，其他方面的優(yōu)化，主要有方法內(nèi)聯(lián)、去虛擬化、冗余消除等。

A、方法內(nèi)聯(lián)

多個方法調(diào)用，執(zhí)行時要經(jīng)歷多次參數(shù)傳遞，返回值傳遞及跳轉(zhuǎn)等，C1采用方法內(nèi)聯(lián)，把調(diào)用到的方法的指令直接植入當前方法中。-XX:+PringInlining來查看方法內(nèi)聯(lián)信息，-XX:MaxInlineSize=35控制編譯后文件大小。

B、去虛擬化

是指在裝載class文件后，進行類層次的分析，如果發(fā)現(xiàn)類中的方法只提供一個實現(xiàn)類，那么對于調(diào)用了此方法的代碼，也可以進行方法內(nèi)聯(lián)，從而提升執(zhí)行的性能。

C、冗余消除

在編譯時根據(jù)運行時狀況進行代碼折疊或消除。

C2編譯器

Server compiler，稱為C2編譯器，較為重量，采用了大量傳統(tǒng)編譯優(yōu)化的技巧來進行優(yōu)化，占用內(nèi)存相對多一些，適合服務器端的應用。和C1的不同主要在于寄存器分配策略及優(yōu)化范圍，寄存器分配策略上C2采用的為傳統(tǒng)的圖著色寄存器分配算法，由于C2會收集程序運行信息，因此其優(yōu)化范圍更多在于全局優(yōu)化，不僅僅是一個方塊的優(yōu)化。收集的信息主要有：分支的跳轉(zhuǎn)/不跳轉(zhuǎn)的頻率、某條指令上出現(xiàn)過的類型、是否出現(xiàn)過空值、是否出現(xiàn)過異常等。

逃逸分析是C2進行很多優(yōu)化的基礎，它根據(jù)運行狀態(tài)來判斷方法中的變量是否會被外部讀取，如不會則認為此變量是不會逃逸的，那么在編譯時會做標量替換、棧上分配和同步消除等優(yōu)化。

（1）標量替換

簡單地說，就是用標量替換聚合量。這樣做的好處是如果創(chuàng)建的對象并未用到其中的全部變量，則可以節(jié)省一定的內(nèi)存。對于代碼執(zhí)行而言，無需去找對象的引用，也會更快一些。

（2）棧上分配

如果point沒有逃逸，那么C2會選擇在棧上直接創(chuàng)建Point對象的實例，而不是在JVM堆上。在棧上分配的好處一方面是加快速度，另一方面是回收時隨著方法的結束，對象被回收了。

（3）同步消除

如果發(fā)現(xiàn)同步的對象未逃逸，那也就沒有必要進行同步了，C2編譯時會直接去掉同步。

C2還會基于擁有的運行信息來做其他優(yōu)化，比如編譯分支頻率執(zhí)行高的代碼等。

運行后C1、C2編譯出來的機器碼如果不再符合優(yōu)化條件，則會進行逆優(yōu)化，也就是回到解釋執(zhí)行的方式，例如基于類層次分析編譯的代碼，當有新的相應的接口來實現(xiàn)類加入時，就執(zhí)行逆優(yōu)化。

OSR編譯

除了C1、C2外，還有OSR（On Stack Replace）編譯，只替換循環(huán)代碼體的入口，C1、C2替換的是方法調(diào)用的入口。因此OSR編譯后會出現(xiàn)的現(xiàn)象是方法的整段代碼被編譯了，但是只有循環(huán)體部分才執(zhí)行編譯后的機器碼，其他部分仍是解釋執(zhí)行。

當機器配置CPU超過2核且內(nèi)存超過2G，默認為server模式，32位的windows始終選擇的是client模式。

分層編譯

Java7默認開啟分層編譯（tiered compilation）策略，由C1編譯器和C2編譯器相互協(xié)作共同來執(zhí)行編譯任務。C1編譯器會對字節(jié)碼進行簡單和可靠的優(yōu)化，以達到更快的編譯速度；C2編譯器會啟動一些編譯耗時更長的優(yōu)化，以獲取更好的編譯質(zhì)量。

1. 解釋器不再收集運行狀態(tài)信息，只用于啟動并觸發(fā)C1編譯
2. C1編譯后生成帶收集運行信息的代碼
3. C2編譯，基于C1編譯后代碼收集的運行信息進行激進優(yōu)化，當激進優(yōu)化的假設不成立時，再退回使用C1編譯的代碼

程序在未編譯期間解釋執(zhí)行有個閾值，SunJDK主要依據(jù)方法上的兩個計數(shù)器是否超過閾值來判斷：

• A、調(diào)用計數(shù)器，即方法被調(diào)用的次數(shù)，CompileThreshold，該值是指當方法被調(diào)用多少次后，就編譯為機器碼，client模式默認為1500次，server模式默認為1萬次，可以在啟動時添加-XX:CompileThreshold=10000來設置該值。

• B、回邊計數(shù)器，即方法中循環(huán)執(zhí)行部分代碼的執(zhí)行次數(shù)，OnStackReplacePercentage，該值用于/參與計算是否觸發(fā)OSR編譯的閾值，client默認為933，sever默認為140，可以通過-XX: OnStackReplacePercentage=140來設置。

client模式下的計算規(guī)則為CompileThreshold*OnStackReplacePercentage/100，
server模式下計算規(guī)則為CompileThreshold*（OnStackReplacePercentage-InterpreterProfilePercentage）/100。InterpreterProfilePercentage，默認為33。

當方法上的回邊計數(shù)器到達這個值時，觸發(fā)后臺的OSR編譯，并將方法上累積的調(diào)用計數(shù)器設置為CompileThreshold 的值，同時將回邊計數(shù)器設置為CompileThreshold/2的值。這樣做一方面是為了避免OSR編譯頻繁被觸發(fā)，另一方面是以便當方法被再次調(diào)用時即觸發(fā)正常的編譯，當累積的回邊計數(shù)器的值再次達到該值時先檢查OSR編譯是否完成，如果已完成，則在執(zhí)行循環(huán)體的代碼時進入編譯后的代碼，如果未完成，繼續(xù)把當前回邊計數(shù)器的累計值再減掉一些，默認情況下，對于回邊的情況，server模式下只要回邊次數(shù)達到10700次（10000*（140-33）），就會觸發(fā)OSR編譯。

解釋器與編譯器并存

如果選用完全解釋策略，那么編譯器將停止所有的工作，字節(jié)碼將完全依靠解釋器逐行解釋執(zhí)行。
如果選用完全編譯策略，那么解釋器仍然會在編譯器無法進行的特殊情況下介入運行，這主要是確保程序能夠最終順序執(zhí)行。

SunJDK之所以未選擇在啟動時即編譯成機器碼的原因如下：

1. 靜態(tài)編譯并不能根據(jù)程序的運行狀態(tài)來優(yōu)化執(zhí)行的代碼，C2這種方式是根據(jù)運行狀態(tài)來進行動態(tài)編譯的，例如分支判斷、逃逸分析等，這些措施會對提升程序執(zhí)行的性能起到很大的幫助，在靜態(tài)編譯的情況下是無法實現(xiàn)的，給C2收集運行數(shù)據(jù)越長的時間，編譯出來的代碼會越優(yōu)。
2. 解釋執(zhí)行比編譯執(zhí)行更節(jié)省內(nèi)存
3. 啟動時解釋執(zhí)行的啟動速度比編譯再啟動更快。

到此這篇關于Java JVM編譯策略案例詳解的文章就介紹到這了,更多相關Java JVM編譯策略內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論