你的 Java 程式碼對 JIT 編譯友好麼？

InfoQ - 段建華發表於2015-09-06
Java編譯

JIT編譯器是Java虛擬機器（以下簡稱JVM）中效率最高並且最重要的組成部分之一。但是很多的程式並沒有充分利用JIT的高效能優化能力，很多開發者甚至也並不清楚他們的程式有效利用JIT的程度。

在本文中，我們將介紹一些簡單的方法來驗證你的程式是否對JIT友好。這裡我們並不打算覆蓋諸如JIT編譯器工作原理這些細節。只是提供一些簡單基礎的檢測和方法來幫助你的程式碼對JIT友好，進而得到優化。

JIT編譯的關鍵一點就是JVM會自動地監控正在被直譯器執行的方法。一旦某個方法被視為頻繁呼叫，這個方法就會被標記，進而編譯成本地機器指令。這些頻繁執行的方法的編譯由後臺的一個JVM執行緒來完成。在編譯完成之前，JVM會執行這個方法的解釋執行版本。一旦該方法編譯完成，JVM會使用將方法排程表中該方法的解釋的版本替換成編譯後的版本。

Hotspot虛擬機器有很多JIT編譯優化的技術，但是其中最重要的一個優化技術就是內聯。在內聯的過程中，JIT編譯器有效地將一個方法的方法體提取到其呼叫者中，從而減少虛方法呼叫。舉個例子，看如下的程式碼：

public int add(int x, int y) {
    return x + y;
}

int result = add(a, b);

當內聯發生之後，上述程式碼會變成

int result = a + b;

上面的變數a和b替換了方法的引數，並且add方法的方法體已經複製到了呼叫者的區域。使用內聯可以為程式帶來很多好處，比如

  • 不會引起額外的效能損失
  • 減少指標的間接引用
  • 不需要對內聯方法進行虛方法查詢

另外，通過將方法的實現複製到呼叫者中，JIT編譯器處理的程式碼增多，使得後續的優化和更多的內聯成為可能。

內聯取決於方法的大小。預設情況下，含有35個位元組碼或更少的方法可以進行內聯操作。對於被頻繁呼叫的方法，臨界值可以達到325個位元組。我們可以通過設定-XX:MaxInlineSize=# 選項來修改最大的臨界值，通過設定‑XX:FreqInlineSize=#選項來修改頻繁呼叫的方法的臨界值。但是在沒有正確的分析的情況下，我們不應該修改這些配置。因為盲目地修改可能會對程式的效能帶來不可預料的影響。

由於內聯會對程式碼的效能有大幅提升，因此讓儘可能多的方法達到內聯條件尤為重要。這裡我們介紹一款叫做Jarscan的工具來幫助我們檢測程式中有多少方法是對內聯友好的。

Jarscan工具是分析JIT編譯的JITWatch開源工具套件中的一部分。和在執行時分析JIT日誌的主工具不同，Jarscan是一款靜態分析jar檔案的工具。該工具的輸出結果格式為CSV，結果中包含了超過頻繁呼叫方法臨界值的方法等資訊。JITWatch和Jarscan是AdoptOpenJDK工程的一部分，該工程由Chris Newland領導。

在使用Jarscan並得到分析結果之前，需要從AdoptOpenJDK Jenkins網站下載二進位制工具（Java 7 工具，Java 8 工具）。

執行很簡單，如下所示

./jarScan.sh <jars to analyse>

更多關於Jarscan的細節可以訪問AdoptOpenJDK wiki進行了解。

上面產生的報告對於開發團隊的開發工作很有幫助，根據報告結果，他們可以查詢程式中是否包含了過大而不能JIT編譯的關鍵路徑方法。上面的操作依賴於手動執行。但是為了以後的自動化，可以開啟Java的-XX:+PrintCompilation 選項。開啟這個選項會生成如下的日誌資訊：

37    1      java.lang.String::hashCode (67 bytes)
124   2  s!  java.lang.ClassLoader::loadClass  (58 bytes)

其中，第一列表示從程式啟動到JIT編譯發生經過的時間，單位為毫秒。第二列表示的是編譯id，表明該方法正在被編譯（在Hotspot中一個方法可以多次去優化和再優化）。第三列表示的是附加的一些標誌資訊，比如s代表synchronized，！代表有異常處理。最後兩列分別代表正在編譯的方法名稱和該方法的位元組大小。

關於PrintCompilation輸出的更多細節，Stephen Colebourne寫過一篇部落格文章詳細介紹日誌結果中各列的具體含義，感興趣的可以訪問這裡閱讀。

PrintCompilation的輸出結果會提供執行時正在編譯的方法的資訊，Jarscan工具的輸出結果可以告訴我們哪些方法不能進行JIT編譯。結合兩者，我們就可以清楚地知道哪些方法進行了編譯，哪些沒有進行。另外，PrintCompilation選項可以線上上環境使用，因為開啟這個選項幾乎不會影響JIT編譯器的效能。

但是，PrintCompilation也存在著兩個小問題，有時候會顯得不是那麼方便：

  1. 輸出的結果中未包含方法的簽名，如果存在過載方法，區分起來則比較困難。
  2. Hotspot虛擬機器目前不能將結果輸出到單獨的檔案中，目前只能是以標準輸出的形式展示。

上述的第二個問題的影響在於PrintCompilation的日誌會和其他常用的日誌混在一起。對於大多數伺服器端程式來說，我們需要一個過濾程式來將PrintCompilation的日誌過濾到一個獨立的日誌中。最簡單的判斷一個方法否是JIT友好的途徑就是遵循下面這個簡單的步驟：

  1. 確定程式中位於要處理的關鍵路徑上的方法。
  2. 檢查這些方法沒有出現在Jarscan的輸出結果中。
  3. 檢查這些方法確實出現在了PrintCompilation的輸出結果中。

如果一個方法超過了內聯的臨界值，大多數情況下最常用的方法就是講這個重要的方法拆分成多個可以進行內聯的小方法，這樣修改之後通常會獲取更好的執行效率。但是對於所有的效能優化而言，優化之前的執行效率需要測量記錄，並且需要需要同優化後的資料進行對比之後，才能決定是否進行優化。為了效能優化而做出的改變不應該是盲目的。

幾乎所有的Java程式都依賴大量的提供關鍵功能的庫。Jarscan可以幫助我們檢測哪些庫或者框架的方法超過了內聯的臨界值。舉一個具體的例子，我們這裡檢查JVM主要的執行時庫 rt.jar檔案。

為了讓結果有點意思，我們分別比較Java 7 和Java 8，並檢視這個庫的變化。在開始之前我們需要安裝Java 7 和 Java8 JDK。首先，我們分別執行Jarscan掃描各自的rt.jar檔案，並得到用來後續分析的報告結果：

   $ ./jarScan.sh /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/jre/lib/rt.jar
  > large_jre_methods_7u71.txt
    $ ./jarScan.sh /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/rt.jar
  > large_jre_methods_8u25.txt

上述操作結束之後，我們得到兩個CSV檔案，一個是JDK 7u71的結果，另一個是JDK 8u25。然後我們看一看不同的版本內聯情況有哪些變化。首先，一個最簡單的判斷驗證方式，看一看不同版本的JRE中有多少對JIT不友好的方法。

$ wc -l large_jre_methods_*
 3684 large_jre_methods_7u71.txt
 3576 large_jre_methods_8u25.txt

我們可以看到，相比Java 7，Java 8 少了100多個內聯不友好的方法。下面繼續深入研究，看看一些關鍵的包的變化。為了便於理解如何操作，我們再次介紹一下Jarscan的輸出結果。Jarscan的輸出結果有如下3個屬性組成：

"<package>","<method name and signature>",<num of bytes>

瞭解了上述的格式，我們可以利用一些Unix文字處理的工具來研究報告結果。比如，我們想看一下Java 7 和 Java 8 這兩個版本中java.lang包下哪些方法變得內聯友好了：

 $ cat large_jre_methods_7u71.txt large_jre_methods_8u25.txt | grep -i
  ^\"java.lang | sort | uniq -c

上面的語句使用grep命令過濾出每份報告中以java.lang開頭的行，即只顯示位於包java.lang中的類的內聯不友好的方法。sort | uniq -c 是一個比較老的Unix小技巧，首先將講行資訊進行排序（相同的資訊將聚集到一起），然後對上面的排序資料進行去重操作。另外本命令還會統計一個當前行資訊重複的次數，這個資料位於每一行資訊的最開始部分。讓我們看一下上述命令的執行結果：

$ cat large_jre_methods_7u71.txt large_jre_methods_8u25.txt | grep -i ^\"java.lang | sort | uniq -c
2 "java.lang.CharacterData00","int getNumericValue(int)",835
2 "java.lang.CharacterData00","int toLowerCase(int)",1339
2 "java.lang.CharacterData00","int toUpperCase(int)",1307
// ... skipped output
2 "java.lang.invoke.DirectMethodHandle","private static java.lang.invoke.LambdaForm makePreparedLambdaForm(java.lang.invoke.MethodType,int)",613
1 "java.lang.invoke.InnerClassLambdaMetafactory","private java.lang.Class spinInnerClass()",497
// ... more output ----

報告中，以2（這是使用了uniq -c 對相同的資訊計算數量的結果）最為起始的條目說明這些方法在Java 7 和Java 8 中起位元組碼大小沒有改變。雖然這並不能完全肯定地說明這些方法的位元組碼沒有改變，但通常我們也可以視為沒有改變。重複次數為1的方法有如下的情況：

a)方法的位元組碼已經改變。

b)這些方法為新的方法。

我們看一下以1開始的行資料

    1 "java.lang.invoke.AbstractValidatingLambdaMetafactory","void
validateMetafactoryArgs()",864
    1 "java.lang.invoke.InnerClassLambdaMetafactory","private
java.lang.Class spinInnerClass()",497
    1 "java.lang.reflect.Executable","java.lang.String
    sharedToGenericString(int,boolean)",329

上面三個對內聯不友好的方法全部來自Java 8，因此這屬於新方法的情況。前兩個方法與lamda表示式實現相關，第三個方法和反射子系統中繼承層級調整有關。在這裡，這個改變就是在Java 8 中引入了方法和構造器可以繼承的通用基類。

最後，我們看一看JDK核心庫一些令人驚訝的特性：

  $ grep -i ^\"java.lang.String large_jre_methods_8u25.txt
  "java.lang.String","public java.lang.String[] split(java.lang.String,int)",326
  "java.lang.String","public java.lang.String toLowerCase(java.util.Locale)",431
  "java.lang.String","public java.lang.String toUpperCase(java.util.Locale)",439

從上面的日誌我們可以瞭解到，即使是Java 8 中一些java.lang.String中一些關鍵的方法還是處於內聯不友好的狀態。尤其是toLowerCase和toUpperCase這兩個方法居然過大而無法內聯，著實讓人感到奇怪。但是，這兩個方法由於要處理UTF-8資料而不是簡單的ASCII資料，進而增加了方法的複雜性和大小，因而超過了內聯友好的臨界值。

對於效能要求較高並且確定只處理ASCII資料的程式，通常我們需要實現一個自己的StringUtils類。該類中包含一些靜態的方法來實現上述內聯不友好的方法的功能，但這些靜態方法既保持緊湊型又能到達內聯的要求。

上述我們討論的改進都是大部分基於靜態分析。除此之外，使用強大的JITWatch工具可以幫助我們更好地優化。JITWatch工具需要設定-XX:+LogCompilation選項開啟日誌列印。其列印出來的日誌為XML格式，而非PrintCompilation簡單的文字輸出，並且這些日誌比較大，通常會到達幾百MB。它會影響正在執行的程式（預設情況下主要來自日誌輸出的影響），因此這個選項不適合線上上的生產環境使用。

PrintCompilation和Jarscan結合使用並不困難，但卻提供了簡單且很有實際作用的一步，尤其是對於開發團隊打算研究其程式中即時編譯執行情況時。大多數情況下，在效能優化中，一個快速的分析可以幫助我們完成一些容易實現的目標。

相關文章