導(dǎo)讀：Java是最廣泛使用的編程語言之一。近日，Oracle發(fā)布了Java的***版本，Java10。在這個版本中，Oracle引入109項新特性，其中最引人注目的就是Java的新Jit編譯器Graal。在這個編譯器中，我們可以使用Java來做Java的Jit編譯器。本文作者詳細介紹了該特性，十分值得一讀。 

Introduction

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

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

Tiered Compilation

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

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

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

• level 1：C1編譯，無profiling

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

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

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

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

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

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

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

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

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

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

Graal v.s. C2

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

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

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

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

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

理想情況下，F(xiàn)oo.bar會被優(yōu)化成如下代碼：

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

Using Graal

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

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

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