Introduction

對(duì)于大部分應(yīng)用開(kāi)發(fā)者來(lái)說(shuō)，Java編譯器指的是JDK自帶的javac指令。這一指令可將Java源程序編譯成.class文件，其中包含的代碼格式我們稱(chēng)之為Java bytecode（Java字節(jié)碼）。這種代碼格式無(wú)法直接運(yùn)行，但可以被不同平臺(tái)JVM中的interpreter解釋執(zhí)行。由于interpreter效率低下，JVM中的JIT compiler（即時(shí)編譯器）會(huì)在運(yùn)行時(shí)有選擇性地將運(yùn)行次數(shù)較多的方法編譯成二進(jìn)制代碼，直接運(yùn)行在底層硬件上。Oracle的HotSpot VM便附帶兩個(gè)用C++實(shí)現(xiàn)的JIT compiler：C1及C2。

與interpreter，GC等JVM的其他子系統(tǒng)相比，JIT compiler并不依賴(lài)于諸如直接內(nèi)存訪問(wèn)的底層語(yǔ)言特性。它可以看成一個(gè)輸入Java bytecode輸出二進(jìn)制碼的黑盒，其實(shí)現(xiàn)方式取決于開(kāi)發(fā)者對(duì)開(kāi)發(fā)效率，可維護(hù)性等的要求。Graal是一個(gè)以Java為主要編程語(yǔ)言，面向Java bytecode的編譯器。與用C++實(shí)現(xiàn)的C1及C2相比，它的模塊化更加明顯，也更加容易維護(hù)。Graal既可以作為動(dòng)態(tài)編譯器，在運(yùn)行時(shí)編譯熱點(diǎn)方法；亦可以作為靜態(tài)編譯器，實(shí)現(xiàn)AOT編譯。在Java 10中，Graal作為試驗(yàn)性JIT compiler一同發(fā)布（JEP 317）。這篇文章將介紹Graal在動(dòng)態(tài)編譯上的應(yīng)用。有關(guān)靜態(tài)編譯，可查閱JEP 295或Substrate VM。

Tiered Compilation

在介紹Graal前，我們先了解HotSpot中的tiered compilation。前面提到，HotSpot集成了兩個(gè)JIT compiler — C1及C2（或稱(chēng)為Client及Server）。兩者的區(qū)別在于，前者沒(méi)有應(yīng)用激進(jìn)的優(yōu)化技術(shù)，因?yàn)檫@些優(yōu)化往往伴隨著耗時(shí)較長(zhǎng)的代碼分析。因此，C1的編譯速度較快，而C2所編譯的方法運(yùn)行速度較快。在Java 7前，用戶(hù)需根據(jù)自己的應(yīng)用場(chǎng)景選擇合適的JIT compiler。舉例來(lái)說(shuō)，針對(duì)偏好高啟動(dòng)性能的GUI用戶(hù)端程序則使用C1，針對(duì)偏好高峰值性能的服務(wù)器端程序則使用C2。

Java 7引入了tiered compilation的概念，綜合了C1的高啟動(dòng)性能及C2的高峰值性能。這兩個(gè)JIT compiler以及interpreter將HotSpot的執(zhí)行方式劃分為五個(gè)級(jí)別：

• level 0：interpreter解釋執(zhí)行

• level 1：C1編譯，無(wú)profiling

• level 2：C1編譯，僅方法及循環(huán)back-edge執(zhí)行次數(shù)的profiling

• level 3：C1編譯，除level 2中的profiling外還包括branch（針對(duì)分支跳轉(zhuǎn)字節(jié)碼）及receiver type（針對(duì)成員方法調(diào)用或類(lèi)檢測(cè)，如checkcast，instnaceof，aastore字節(jié)碼）的profiling

• level 4：C2編譯其中，1級(jí)和4級(jí)為接受狀態(tài) — 除非已編譯的方法被invalidated（通常在deoptimization中觸發(fā)），否則HotSpot不會(huì)再發(fā)出該方法的編譯請(qǐng)求。

  
  

上圖列舉了4種編譯模式（非全部）。通常情況下，一個(gè)方法先被解釋執(zhí)行（level 0），然后被C1編譯（level 3），再然后被得到profile數(shù)據(jù)的C2編譯（level 4）。如果編譯對(duì)象非常簡(jiǎn)單，虛擬機(jī)認(rèn)為通過(guò)C1編譯或通過(guò)C2編譯并無(wú)區(qū)別，便會(huì)直接由C1編譯且不插入profiling代碼（level 1）。在C1忙碌的情況下，interpreter會(huì)觸發(fā)profiling，而后方法會(huì)直接被C2編譯；在C2忙碌的情況下，方法則會(huì)先由C1編譯并保持較少的profiling（level 2），以獲取較高的執(zhí)行效率（與3級(jí)相比高30%）。

Graal可替換C2成為HotSpot的頂層JIT compiler，即上述level 4。與C2相比，Graal采用更加激進(jìn)的優(yōu)化方式，因此當(dāng)程序達(dá)到穩(wěn)定狀態(tài)后，其執(zhí)行效率（峰值性能）將更有優(yōu)勢(shì)。

早期的Graal同C1及C2一樣，與HotSpot是緊耦合的。這意味著每次編譯Graal均需重新編譯HotSpot。JEP 243將Graal中依賴(lài)于HotSpot的代碼分離出來(lái)，形成Java-Level JVM Compiler Interface（JVMCI）。該接口主要提供如下三種功能：

• 響應(yīng)HotSpot的編譯請(qǐng)求，并分發(fā)給Java-Level JIT compiler

• 允許Java-Level JIT compiler訪問(wèn)HotSpot中與JIT compilation相關(guān)的數(shù)據(jù)結(jié)構(gòu)，包括類(lèi)，字段，方法及其profiling數(shù)據(jù)等，并提供這些數(shù)據(jù)結(jié)構(gòu)在Java層面的抽象

• 提供HotSpot codecache的Java抽象，允許Java-Level JIT compiler部署編譯完成的二進(jìn)制代碼

綜合利用這三種功能，我們可以將Java-Level編譯器（不局限于Graal）集成至HotSpot中，響應(yīng)HotSpot發(fā)出的level 4的編譯請(qǐng)求并將編譯后的二進(jìn)制代碼部署到HotSpot的codecache中。此外，單獨(dú)利用上述第三種功能可以繞開(kāi)HotSpot的編譯系統(tǒng) — Java-Level編譯器將作為上層應(yīng)用的類(lèi)庫(kù)直接部署編譯后的二進(jìn)制代碼。Graal自身的單元測(cè)試便是依賴(lài)于直接部署而非等待HotSpot發(fā)出編譯請(qǐng)求；Truffle亦是通過(guò)此機(jī)制部署編譯后的語(yǔ)言解釋器。

Graal v.s. C2

前面提到，JIT Compiler并不依賴(lài)于底層語(yǔ)言特性，它僅僅是一種代碼形式到另一種代碼形式的轉(zhuǎn)換。因此，理論上任意C2中以C++實(shí)現(xiàn)的優(yōu)化均可以在Graal中通過(guò)Java實(shí)現(xiàn)，反之亦然。事實(shí)上，許多C2中實(shí)現(xiàn)的優(yōu)化均被移植到Graal中，如近期由其他開(kāi)發(fā)者貢獻(xiàn)的String.compareTo intrinsic的移植。當(dāng)然，局限于C++的開(kāi)發(fā)/維護(hù)難度（個(gè)人猜測(cè)），許多Graal中被證明有效的優(yōu)化并沒(méi)有被成功移植到C2上，這其中就包含Graal的inlining算法及partial escape analysis（PEA）。

Inlining是指在編譯時(shí)識(shí)別callsite的目標(biāo)方法，將其方法體納入編譯范圍并用其返回結(jié)果替換原callsite。最簡(jiǎn)單直觀的例子便是Java中常見(jiàn)的getter/setter方法 — inlining可以將一個(gè)方法中調(diào)用getter/setter的callsite優(yōu)化成單一內(nèi)存訪問(wèn)指令。Inlining被業(yè)內(nèi)戲稱(chēng)為優(yōu)化之母，其原因在于它能引發(fā)更多優(yōu)化。然而在實(shí)踐中我們往往受制于編譯單元大小或編譯時(shí)間的限制，無(wú)法無(wú)限制地遞歸inline。因此，inlining的算法及策略很大程度上決定了編譯器的優(yōu)劣，尤其是在使用Java 8的stream API或使用Scala語(yǔ)言的場(chǎng)景下。這兩種場(chǎng)景對(duì)應(yīng)的Java bytecode包含大量的多層單方法調(diào)用。

Graal擁有兩個(gè)inliner實(shí)現(xiàn)。社區(qū)版的inliner采用的是深度優(yōu)先的搜索方式，在分析某一方法時(shí)，一旦遇到不值得inline的callsite時(shí)便回溯至該方法的調(diào)用者。Graal允許自定義策略以判斷某一callsite值不值得inline。默認(rèn)情況下，Graal會(huì)采取一種相對(duì)貪婪的策略，根據(jù)callsite的目標(biāo)方法的大小做出相應(yīng)的決定。Graal enterprise的inliner則對(duì)所有callsite進(jìn)行加權(quán)排序，其加權(quán)算法取決于目標(biāo)方法的大小以及可能引發(fā)的優(yōu)化。當(dāng)目標(biāo)方法被inline后，其包含的callsite同樣會(huì)進(jìn)入該加權(quán)隊(duì)列中。這兩種搜索方式都較為適合擁有多層單方法調(diào)用的應(yīng)用場(chǎng)景。

Escape analysis（逃逸分析，EA）是一類(lèi)識(shí)別對(duì)象動(dòng)態(tài)范圍的程序分析。編譯器中常見(jiàn)的應(yīng)用有兩類(lèi)：如果對(duì)象僅被單一線(xiàn)程訪問(wèn)，則可去除針對(duì)該對(duì)象的鎖操作；如果對(duì)象為堆分配且僅被單一方法訪問(wèn)（inlining的重要性再次體現(xiàn)），則可將該對(duì)象轉(zhuǎn)化成棧分配。后者通常伴隨著scalar replacement，即將對(duì)對(duì)象字段的訪問(wèn)替換成對(duì)虛擬局部操作數(shù)的訪問(wèn)，從而進(jìn)一步將對(duì)象由棧分配轉(zhuǎn)換成虛擬分配。這不僅節(jié)省了原本用于存放對(duì)象header的內(nèi)存空間，而且可以在register allocator的幫助下將（部分）對(duì)象字段存放在寄存器中，在節(jié)省內(nèi)存的同時(shí)提高執(zhí)行效率（內(nèi)存訪問(wèn)轉(zhuǎn)換成寄存器訪問(wèn)）。

Java中常見(jiàn)的for-each loop是EA的一大目標(biāo)客戶(hù)。我們知道for-each loop會(huì)調(diào)用被遍歷對(duì)象的iterator方法，返回一個(gè)實(shí)現(xiàn)interface Iterator的對(duì)象，并利用其hasNext及next接口進(jìn)行遍歷。Java collections中的容器類(lèi)（如ArrayList）通常會(huì)構(gòu)造一個(gè)新的Iterator實(shí)例，其生命周期局限于該for-each loop中。如若Iterator實(shí)例的構(gòu)造函數(shù)以及hasNext，next方法調(diào)用（連同它們方法體中以this為receiver的方法調(diào)用，如checkForComodification()）都被inline，EA會(huì)認(rèn)為該實(shí)例沒(méi)有逃逸，并采取棧分配及scalar replacement。

理想情況下，Foo.bar會(huì)被優(yōu)化成如下代碼：

HotSpot的C2便已應(yīng)用控制流無(wú)關(guān)的EA實(shí)現(xiàn)scalar replacement。而Graal的PEA則在此基礎(chǔ)上引入了控制流信息，將所有的堆分配操作虛擬化，并僅在對(duì)象確定逃逸的分支materialize。與C2的EA相比，PEA分析效率較低，但能夠在對(duì)象沒(méi)有逃逸的分支上實(shí)現(xiàn)scalar replacement。如下例所示，如果then-branch的執(zhí)行概率為1%，那么被PEA優(yōu)化后的代碼在99%的情況下并不會(huì)執(zhí)行堆分配，而C2的EA則100%會(huì)執(zhí)行堆分配。另一個(gè)典型的例子是渲染引擎Sunflow — 在運(yùn)行DaCapo benchmark suite所附帶的默認(rèn)workload時(shí)，Graal的PEA判定約27%的堆分配（共占700M）可被虛擬化。該數(shù)字遠(yuǎn)超C2的EA。

Using Graal

在Java 10 (Linux/x64, macOS/x64)中，默認(rèn)情況下HotSpot仍使用C2，但通過(guò)向java命令添加-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler參數(shù)便可將C2替換成Graal。

Oracle Labs GraalVM是由Oracle Labs直接發(fā)布的JDK版本。它基于Java 8，并且囊括了Graal enterprise。如果對(duì)源代碼感興趣，可直接簽出Graal社區(qū)版的GitHub repo。源代碼的編譯需借助mx工具及l(fā)absjdk（注：請(qǐng)下載頁(yè)面最下方的labsjdk，直接使用GraalVM可能會(huì)導(dǎo)致編譯問(wèn)題）。

在graal/compiler目錄下使用mx eclipseinit，mx intellijinit或mx netbeansinit可分別生成Eclipse，IntelliJ或NetBeans的工程配置文件。

廣告時(shí)間

沒(méi)辦法，好多朋友要找我免費(fèi)打點(diǎn)廣告，這次還不趁機(jī)說(shuō)說(shuō)估計(jì)會(huì)找我麻煩了，有需要的自取，打擾各位了

• 前不久我們發(fā)布的JVM參數(shù)分析產(chǎn)品XXFox，可以一鍵生成JVM參數(shù)，并能檢查你們現(xiàn)有JVM參數(shù)是否存在一些問(wèn)題，有沒(méi)有體驗(yàn)過(guò)的可以體驗(yàn)一下，http://xxfox.perfma.com，可以點(diǎn)擊下面的【原文閱讀】進(jìn)去體驗(yàn)

• 我們團(tuán)隊(duì)Base在杭州，希望能?chē)@JVM做一些性能分析相關(guān)的產(chǎn)品，有興趣的小伙伴請(qǐng)加入我們

  
  
  

• 相關(guān)閱讀：

  
  

• 深入解讀 Java 9 新特性

• Java 微服務(wù)框架新選擇：Spring 5

  
  

本文作者二維碼

總結(jié)

以上是生活随笔為你收集整理的Java10来了，来看看它一同发布的全新JIT编译器的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。