編者按:目前許多公司同時使用 x86 和 AArch64 2 種主流的服務器。這兩種環(huán)境的算力相當,內存相同的情況下:相同版本的 JVM 和 Java 應用,相同的 JVM 參數(shù),應用性能在不同的平臺中表現(xiàn)相差 30%,x86 遠好于 AArch64 平臺。本文分析了一個應用在 AArch64 平臺上性能下降的例子,發(fā)現(xiàn) JVM 的 CodeCache 大小是引起這個性能問題的根源,進而研究什么導致了不同平臺上 CodeCache 大小的不同。最后筆者給出了不同平臺中該如何設置參數(shù)規(guī)避該問題。希望本文能給讀者一些啟示:當使用不同的硬件平臺時需要關注底層硬件對于上層應用的影響。
業(yè)務在 x86 和 AArch64 上同時部署時(相同的 JDK 和 Java 應用版本),發(fā)現(xiàn) AArch64 平臺性能下降嚴重問題。進一步查看日志,發(fā)現(xiàn)在 AArch64 平臺中偶有如下情況:
這代表 JVM 中的 CodeCache 滿了,導致編譯停止,未編譯的方法只能解釋執(zhí)行,進而嚴重影響應用性能。那什么是 CodeCache?
CodeCache 是什么
簡單來說,CodeCache 用于存放編譯后的方法,主要分為三部分:
Non-nmethods:包括運行時 Stub,Adapter 等;
Profiled nmethod:包括會采集信息的方法,即分層編譯中第 2、3 層的方法;
Non-Profiled nmethods:包括不采集信息的方法,即分層編譯中第 1、4 層的方法,也包括 JNI 的方法。
注:分層編譯指的是 JVM 同時存在 C1 和 C2 兩種編譯器,C1 做一些簡單的編譯優(yōu)化,耗時較短,C2 做更多復雜的編譯優(yōu)化,性能較好,編譯耗時較多。分層編譯的觸發(fā)在 JVM 內會根據(jù)相應的條件進行觸發(fā),關于更多分層編譯相關知識可以參考相關資料 [1]。
在 JDK 9 之后 [2],這些會分配到不同的區(qū)域(使用不同區(qū)域的優(yōu)點:查找、回收等),JDK 8 中會分配到同一塊區(qū)域。
JVM 平時會清理一些不可達的方法,例如由于退優(yōu)化等產(chǎn)生的死方法,另外 UseCodeCacheFlushing 選項(默認開啟),還會清理較老以及執(zhí)行較少的方法。一旦 CodeCache 滿了之后,會停止編譯,直到 CodeCache 有空間,若關閉了 UseCodeCacheFlushing 選項,則會直接永久停止編譯。
不同的 JVM 版本以及不同的參數(shù),默認的 CodeCache 大小不同。JDK 11 中默認參數(shù)下 CodeCache 大小為 240M,若想獲?。ù_認)默認情況下的 CodeCache 大小,建議使用 - XX:+PrintFlagsFinal 選項獲取 ReservedCodeCache 的大小。
CodeCache 大小主要通過以下選項調節(jié):
InitialCodeCacheSize | 初始的 CodeCache 大?。▎挝蛔止?jié)) |
ReservedCodeCacheSize | 預留的 CodeCache 大小,即最大CodeCache 大?。▎挝蛔止?jié)) |
CodeCacheExpansionSize | CodeCache 每次擴展大?。▎挝蛔止?jié)) |
Option | Description |
---|
使用–XX:+PrintCodeCache 選項可以打印應用使用的 CodeCache 情況,如下:
其中 max_used 表示應用中使用到的 CodeCache 大小,據(jù)此可以設置合適的 ReservedCodeCacheSize 值。
AArch64 vs x86_64
我們都知道 AArch64 和 x86 分別為 RISC 和 CISC 架構,因此代碼密度方面存在一定差異,在這篇文章 [3] 中比較了不同指令集下手寫匯編的大小,可以看到 AArch64 的代碼密度是 RISC 架構中較優(yōu)的,但相比 x86_64 仍稍差些(其中 RISC 最差,m68k 最好)。
另外筆者選用業(yè)界通用的 java 測試套 dacapo[4] 比較 AArch64 和 x86_64 下 CodeCache 占用的大小。
可以看到,在 AArch64 架構下,CodeCache 均比 x86_64 要大,但根據(jù)不同場景,大小差距不同,在 5%-20% 之間。因此在我們發(fā)現(xiàn)相同應用在 x86 和 AArch64 上時,CodeCache 大小需要進行相應的調節(jié)。
除此之外,還需要注意 InlineSmallCode 選項,JVM 只會 inline 代碼體積比該值小的方法。JVM 通過 inline 可以觸發(fā)更多的優(yōu)化,因此 inline 對于性能提升也很重要。在 JDK 11 中,InlineSmallCode 在 x86 下的默認值為 2000 字節(jié),在 AArch64 下的默認值為 2500 字節(jié)。而 JDK 8 中,InlineSmallCode 在 x86 和 AArch64 下默認值均為 2000 字節(jié)。因此建議遷移時也相應修改 InlineSmallCode 的值。業(yè)務通過對 CodeCache 相關參數(shù)的調整,達到助力 JIT 的最佳編譯效果。
后記
如果遇到相關技術問題(包括不限于畢昇 JDK),可以進入畢昇 JDK 社區(qū)查找相關資源(點擊原文進入官網(wǎng)),包括二進制下載、代碼倉庫、使用教學、安裝、學習資料等。畢昇 JDK 社區(qū)每雙周周二舉行技術例會,同時有一個技術交流群討論 GCC、LLVM、JDK 和 V8 等相關編譯技術,感興趣的同學可以添加如下微信小助手,回復 Compiler 入群。
責任編輯:haq
-
服務器
+關注
關注
13文章
9795瀏覽量
88002 -
JAVA
+關注
關注
20文章
2989瀏覽量
109825 -
JVM
+關注
關注
0文章
160瀏覽量
12626
原文標題:相同版本 JVM 和 Java 應用,在 x86 和AArch64 平臺性能相差30%,何故?
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
【HZ-T536開發(fā)板免費體驗】2 - 交叉編譯倉頡編程語言程序到開發(fā)板運行
【HZ-RK3568開發(fā)板免費體驗】合眾HZ-RK3568開發(fā)環(huán)境搭建
能在Meteor Lake平臺上使用SDK 3.5嗎?
可以手動構建imx-gpu-viv嗎?
stm32F407平臺上使用freertos,使用pvPortMalloc申請內存,發(fā)現(xiàn)內存中的數(shù)據(jù)總被修改,怎么解決?
【米爾RK3576開發(fā)板評測】+項目名稱YOLOV5目標檢測
E2000 Speedometer測試瀏覽器性能
HAL庫在Arduino平臺上的使用
在基于TMS320C64x的DSP平臺上運行TMS320C64x編解碼器

【飛凌嵌入式OK3576-C開發(fā)板體驗】RKNN神經(jīng)網(wǎng)絡-YOLO目標檢測
請問TLV320ADC6140在NXP的iMX6UL平臺上如何配置route?
STM32平臺新選擇:Nand Flash(貼片TF卡)的應用解析

MK米客方德SD NAND:STM32平臺上的存儲方案

第四章:在 PC 交叉編譯 aarch64 的 tensorflow 開發(fā)環(huán)境并測試

評論