相同版本?JVM?和?Java?應(yīng)用，在?x86?和AArch64?平臺(tái)性能相差30%，何故？

編者按：目前許多公司同時(shí)使用 x86 和 AArch64 2 種主流的服務(wù)器。這兩種環(huán)境的算力相當(dāng)，內(nèi)存相同的情況下：相同版本的 JVM 和 Java 應(yīng)用，相同的 JVM 參數(shù)，應(yīng)用性能在不同的平臺(tái)中表現(xiàn)相差 30%，x86 遠(yuǎn)好于 AArch64 平臺(tái)。本文分析了一個(gè)應(yīng)用在 AArch64 平臺(tái)上性能下降的例子，發(fā)現(xiàn) JVM 的 CodeCache 大小是引起這個(gè)性能問題的根源，進(jìn)而研究什么導(dǎo)致了不同平臺(tái)上 CodeCache 大小的不同。最后筆者給出了不同平臺(tái)中該如何設(shè)置參數(shù)規(guī)避該問題。希望本文能給讀者一些啟示：當(dāng)使用不同的硬件平臺(tái)時(shí)需要關(guān)注底層硬件對(duì)于上層應(yīng)用的影響。

業(yè)務(wù)在 x86 和 AArch64 上同時(shí)部署時(shí)（相同的 JDK 和 Java 應(yīng)用版本），發(fā)現(xiàn) AArch64 平臺(tái)性能下降嚴(yán)重問題。進(jìn)一步查看日志，發(fā)現(xiàn)在 AArch64 平臺(tái)中偶有如下情況：

這代表 JVM 中的 CodeCache 滿了，導(dǎo)致編譯停止，未編譯的方法只能解釋執(zhí)行，進(jìn)而嚴(yán)重影響應(yīng)用性能。那什么是 CodeCache？

CodeCache 是什么

簡(jiǎn)單來說，CodeCache 用于存放編譯后的方法，主要分為三部分：

1. Non-nmethods：包括運(yùn)行時(shí) Stub，Adapter 等；
2. Profiled nmethod：包括會(huì)采集信息的方法，即分層編譯中第 2、3 層的方法；
3. Non-Profiled nmethods：包括不采集信息的方法，即分層編譯中第 1、4 層的方法，也包括 JNI 的方法。

注：分層編譯指的是 JVM 同時(shí)存在 C1 和 C2 兩種編譯器，C1 做一些簡(jiǎn)單的編譯優(yōu)化，耗時(shí)較短，C2 做更多復(fù)雜的編譯優(yōu)化，性能較好，編譯耗時(shí)較多。分層編譯的觸發(fā)在 JVM 內(nèi)會(huì)根據(jù)相應(yīng)的條件進(jìn)行觸發(fā)，關(guān)于更多分層編譯相關(guān)知識(shí)可以參考相關(guān)資料 [1]。

在 JDK 9 之后 [2]，這些會(huì)分配到不同的區(qū)域（使用不同區(qū)域的優(yōu)點(diǎn)：查找、回收等），JDK 8 中會(huì)分配到同一塊區(qū)域。

JVM 平時(shí)會(huì)清理一些不可達(dá)的方法，例如由于退優(yōu)化等產(chǎn)生的死方法，另外 UseCodeCacheFlushing 選項(xiàng)（默認(rèn)開啟），還會(huì)清理較老以及執(zhí)行較少的方法。一旦 CodeCache 滿了之后，會(huì)停止編譯，直到 CodeCache 有空間，若關(guān)閉了 UseCodeCacheFlushing 選項(xiàng)，則會(huì)直接永久停止編譯。

不同的 JVM 版本以及不同的參數(shù)，默認(rèn)的 CodeCache 大小不同。JDK 11 中默認(rèn)參數(shù)下 CodeCache 大小為 240M，若想獲?。ù_認(rèn)）默認(rèn)情況下的 CodeCache 大小，建議使用 - XX: PrintFlagsFinal 選項(xiàng)獲取 ReservedCodeCache 的大小。

CodeCache 大小主要通過以下選項(xiàng)調(diào)節(jié)：

Option	Description
InitialCodeCacheSize	初始的 CodeCache 大?。▎挝蛔止?jié)）
ReservedCodeCacheSize	預(yù)留的 CodeCache 大小，即最大CodeCache 大?。▎挝蛔止?jié)）
CodeCacheExpansionSize	CodeCache 每次擴(kuò)展大?。▎挝蛔止?jié)）

使用–XX: PrintCodeCache 選項(xiàng)可以打印應(yīng)用使用的 CodeCache 情況，如下：

其中 max_used 表示應(yīng)用中使用到的 CodeCache 大小，據(jù)此可以設(shè)置合適的 ReservedCodeCacheSize 值。

AArch64 vs x86_64

我們都知道 AArch64 和 x86 分別為 RISC 和 CISC 架構(gòu)，因此代碼密度方面存在一定差異，在這篇文章 [3] 中比較了不同指令集下手寫匯編的大小，可以看到 AArch64 的代碼密度是 RISC 架構(gòu)中較優(yōu)的，但相比 x86_64 仍稍差些（其中 RISC 最差，m68k 最好）。

另外筆者選用業(yè)界通用的 java 測(cè)試套 dacapo[4] 比較 AArch64 和 x86_64 下 CodeCache 占用的大小。

可以看到，在 AArch64 架構(gòu)下，CodeCache 均比 x86_64 要大，但根據(jù)不同場(chǎng)景，大小差距不同，在 5%-20% 之間。因此在我們發(fā)現(xiàn)相同應(yīng)用在 x86 和 AArch64 上時(shí)，CodeCache 大小需要進(jìn)行相應(yīng)的調(diào)節(jié)。

除此之外，還需要注意 InlineSmallCode 選項(xiàng)，JVM 只會(huì) inline 代碼體積比該值小的方法。JVM 通過 inline 可以觸發(fā)更多的優(yōu)化，因此 inline 對(duì)于性能提升也很重要。在 JDK 11 中，InlineSmallCode 在 x86 下的默認(rèn)值為 2000 字節(jié)，在 AArch64 下的默認(rèn)值為 2500 字節(jié)。而 JDK 8 中，InlineSmallCode 在 x86 和 AArch64 下默認(rèn)值均為 2000 字節(jié)。因此建議遷移時(shí)也相應(yīng)修改 InlineSmallCode 的值。業(yè)務(wù)通過對(duì) CodeCache 相關(guān)參數(shù)的調(diào)整，達(dá)到助力 JIT 的最佳編譯效果。

后記

如果遇到相關(guān)技術(shù)問題（包括不限于畢昇 JDK），可以進(jìn)入畢昇 JDK 社區(qū)查找相關(guān)資源（點(diǎn)擊原文進(jìn)入官網(wǎng)），包括二進(jìn)制下載、代碼倉庫、使用教學(xué)、安裝、學(xué)習(xí)資料等。畢昇 JDK 社區(qū)每雙周周二舉行技術(shù)例會(huì)，同時(shí)有一個(gè)技術(shù)交流群討論 GCC、LLVM、JDK 和 V8 等相關(guān)編譯技術(shù)，感興趣的同學(xué)可以添加如下微信小助手，回復(fù) Compiler 入群。

rc="https://img.21ic.com/weixin/tr/2021-09/10/436pnetg802.png">

參考

[1]http://cr.openjdk.java.net/~thartmann/talks/2017-hotspot_under_the_hood.pdf

[2]https://bugs.openjdk.java.net/browse/jdk-8015774

[3]http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf

[4]http://dacapobench.org/