Java10來了，來看看它一同發布的全新JIT編譯器

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

Introduction

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

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

Tiered Compilation

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

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

• level 0：interpreter解釋執行

• level 1：C1編譯，無profiling

• level 2：C1編譯，僅方法及循環back-edge執行次數的profiling

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

• level 4：C2編譯

  其中，1級和4級為接受狀態 — 除非已編譯的方法被invalidated（通常在deoptimization中觸發），否則HotSpot不會再發出該方法的編譯請求。

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

Graal可替換C2成為HotSpot的頂層JIT compiler，即上述level 4。與C2相比，Graal采用更加激進的優化方式，因此當程序達到穩定狀態后，其執行效率（峰值性能）將更有優勢。

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

• 響應HotSpot的編譯請求，并分發給Java-Level JIT compiler

• 允許Java-Level JIT compiler訪問HotSpot中與JIT compilation相關的數據結構，包括類，字段，方法及其profiling數據等，并提供這些數據結構在Java層面的抽象

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

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

Graal v.s. C2

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

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

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

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

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

理想情況下，Foo.bar會被優化成如下代碼：

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

Using Graal

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

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

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

 

來自：http://developer.51cto.com/art/201803/568607.htm