編者按：筆者遇到一個(gè)非常典型的問題，應(yīng)用在 X86 正常運(yùn)行，在 AArch64 上 JVM 就會(huì)崩潰。這個(gè)典型的 JVM 內(nèi)部問題。筆者通過分析最終定位到是由于 JVM 中模板解釋器代碼存在 bug 導(dǎo)致在弱內(nèi)存模型的平臺(tái)上 Crash。在分析過程中，涉及到非常多的 JVM 內(nèi)部知識(shí)，比如對(duì)象頭、GC 復(fù)制算法操作、CAS 操作、字節(jié)碼執(zhí)行、內(nèi)存序等，希望對(duì)讀者有所幫助。本文介紹了一般分析 JVM crash 的方法，并且深入介紹了為什么在 aarch64 平臺(tái)上引起這樣的問題，最后還給出了修改方法并推送到上游社區(qū)中。**對(duì)于使用非畢昇 JDK 的其他 JDK 只有在 jdk8u292、jdk11.0.9、jdk15以后的版本才得到修復(fù)，讀者使用時(shí)需要注意版本選擇避免這類問題發(fā)生。

背景知識(shí)

java 程序在發(fā)生 crash 時(shí)，會(huì)生成 hs_err_pid.log 文件，以及 core 文件（需要操作系統(tǒng)開啟相關(guān)設(shè)置），其中 hs_err 文件以文本格式記錄了 crash 發(fā)生位置的小范圍精確現(xiàn)場信息（調(diào)用棧、寄存器、線程棧、致命信號(hào)、指令上下文等）、jvm 各組件狀態(tài)信息（java 堆、jit 事件、gc 事件）、系統(tǒng)層面信息（環(huán)境變量、入?yún)?、?nèi)存使用信息、系統(tǒng)版本）等，精簡記錄了關(guān)鍵信息。而 core 文件是程序崩潰時(shí)進(jìn)程的二進(jìn)制快照，完整記錄了崩潰現(xiàn)場信息，可以使用 gdb 工具來打開 core 文件，恢復(fù)出一個(gè)崩潰現(xiàn)場，方便分析。

約束

文中描述的問題適用于 jdk8u292 之前的版本。

現(xiàn)象

某業(yè)務(wù)線隔十天半個(gè)月總會(huì)報(bào)過來 crash 問題，crash 位置比較統(tǒng)一，都是在某處執(zhí)行 young gc 的上下文中，crash 的直接原因是 java 對(duì)象的頭被寫壞了，比如這樣：

而正常的對(duì)象頭由 markoop 和 metadata 兩部分組成，前者存放該對(duì)象的 hash 值、年齡、鎖信息等，后者存放該對(duì)象所屬的 Klass 指針。這里關(guān)注的是 markoop，64 位機(jī)器上它的具體布局如下：

每種布局中每個(gè)字段的詳細(xì)含義可以在 jdk 源碼 jdk8u/hotspot/src/share/vm/oops/markOop.hpp 中找到，這里簡單給出結(jié)論就是 gc 階段一個(gè)正常對(duì)象頭中的 markoop 不可能是全 0，而是比如這樣：

此外，crash 時(shí)間上也有個(gè)特點(diǎn)：基本每次都發(fā)生在程序剛啟動(dòng)時(shí)的幾秒內(nèi)。

分析

發(fā)生 crash 的 java 對(duì)象有個(gè)一致的特點(diǎn)，就是總位于 eden 區(qū)，我們仔細(xì)分析了 crash 位置的 gc 過程邏輯，特別是會(huì)在 gc 期間修改對(duì)象頭的相關(guān)源碼更是重點(diǎn)關(guān)注對(duì)象，因?yàn)槟菈K代碼為了追求性能，使用了無鎖編程：

補(bǔ)充介紹一下 CAS(Compare And Swap)，CAS 的完整意思是比較并替換，并且確保整個(gè)操作原子性。CAS 需要 3 個(gè)操作數(shù)：內(nèi)存地址 dst，比較值 cmp，要更新的目標(biāo)值 value。當(dāng)且僅當(dāng)內(nèi)存地址 dst 上的值跟比較值 cmp 相等時(shí)，將內(nèi)存地址 dst 上的值改寫為 value，否則就什么都不做，其在 aarch64 上的匯編實(shí)現(xiàn)類似如下：

然而我們經(jīng)過反復(fù)推敲，這塊 gc 邏輯似乎無懈可擊，而且位于 eden 區(qū)也意味著沒有被 gc 搬移過的可能性，這個(gè)問題在很長時(shí)間里陷入了停滯……

直到某一天又收到了一個(gè)類似的 crash，這個(gè)問題才迎來了轉(zhuǎn)機(jī)。在這個(gè) crash 里，也是 java 對(duì)象的頭被寫壞了，但特殊的地方在于，頭上的錯(cuò)誤值是 0x2000，憑著職業(yè)敏感，我們猜測(cè)這個(gè)特殊的錯(cuò)誤值是否來自這個(gè) java 對(duì)象本身呢？這個(gè)對(duì)象的 Java 名字叫 DynamicByteBuffer，來自某個(gè)基礎(chǔ)組件。反編譯得到了問題類 DynamicByteBuffer 的代碼：

再結(jié)合 core 信息中其他正常 DynamicByteBuffer 對(duì)象的布局，確定了這個(gè)特殊的 0x2000 值原本應(yīng)該位于 segmentSize 字段上，而且從代碼中注意到這個(gè) segmentSize 字段是 final 屬性，意味著其值只可能在實(shí)例構(gòu)造函數(shù)中被設(shè)置，使用 jdk 自帶的命令 javap 進(jìn)行反匯編，得到對(duì)應(yīng)的字節(jié)碼如下：

putfield 這條字節(jié)碼的作用是給 java 對(duì)象的一個(gè)字段賦值，在紅框中的語義就是給 DynamicByteBuffer 對(duì)象的 segmentSize 字段賦值。

分析到這里，我們做一下小結(jié)，crash 的第一現(xiàn)場并非在 gc 上下文中，而是得往前追溯，發(fā)生在這個(gè) java 對(duì)象被初始化期間，這期間在初始化它的 segmentSize 字段時(shí)，因?yàn)槟撤N原因，0x2000 被寫到了對(duì)象頭上。

接下來繼續(xù)分析， JDK 在發(fā)生 crash 時(shí)會(huì)自動(dòng)生成的 hs_err 日志，其中有記錄最近發(fā)生的編譯事件 “Compilation events (250 events)”，從中沒有發(fā)現(xiàn) DynamicByteBuffer 構(gòu)造函數(shù)相關(guān)的編譯事件，所以可以推斷 crash 時(shí) DynamicByteBuffer 這個(gè)類的構(gòu)造函數(shù)尚未被編譯過（由于 crash 發(fā)生在程序啟動(dòng)那幾秒，JIT 往往需要預(yù)熱后才會(huì)介入，所以可以假設(shè)記錄的比較完整），這意味著，它的構(gòu)造函數(shù)只會(huì)通過模板解釋器去執(zhí)行，更具體地說，是去執(zhí)行模板解釋器中的 putfield 指令來把 0x2000 寫到 segmentSize 字段位置。

具體怎么寫其實(shí)很簡單，就是先拿到 segmentSize 字段的偏移量，根據(jù)偏移量定位到寫的位置，然后寫入。然而 JVM 的模板解釋器在實(shí)現(xiàn)這個(gè) putfield 指令時(shí)，額外增加了一條快速實(shí)現(xiàn)路徑，在 runtime 期間會(huì)自動(dòng)（具體的時(shí)間點(diǎn)是 “完整” 執(zhí)行完第一次 putfield 指令后）從慢速路徑切到快速路徑上，這個(gè)切換操作的實(shí)現(xiàn)全程沒有加鎖，同步完全依賴 barrier，由于整個(gè)過程比較復(fù)雜，這里首先給一個(gè)比較容易理解的并行流程圖：

注：圖中 bcp 指的是 bytecode pointer，就是讀字節(jié)碼。

上圖表示接近同一時(shí)間點(diǎn)前后，兩條并行流分別構(gòu)建一個(gè) DynamicByteBuffer 類型的對(duì)象過程中，各自完成 segmentSize 字段賦值的過程，用 Java 代碼簡單示意如下：

其中第一條執(zhí)行流走的慢速路徑，第二條走的快速路徑，可以留意到，紅色標(biāo)識(shí)的是幾次公共內(nèi)存的訪存操作，barrier 就分布在這些位置前后（標(biāo)在下圖中）。

接下來再給一個(gè)更加精確一點(diǎn)的指令流模型：

簡單介紹一下這個(gè)設(shè)計(jì)模型：

1. 線程從記錄了指令的內(nèi)存地址 bcp(bytecode pointer) 上取出指令，然后跳轉(zhuǎn)到該指令地址上執(zhí)行，當(dāng)取出的指令是 bcp1（比如 putfeild 指令的慢速路徑）時(shí)就是圖中左邊的指令流；
2. 左邊的指令流就是計(jì)算出字段的 offset 并 str 到指定內(nèi)存地址，然后插入 barrier，最后將 bcp2 指令（比如 putfeild 指令的快速路徑）覆寫到步驟 1 中的內(nèi)存地址 addr 上；
3. 后續(xù)線程繼續(xù)執(zhí)行步驟 1 時(shí)，由于取出的指令變成了 bcp2，就改為跳轉(zhuǎn)到圖中右邊的指令流；
4. 右邊的指令流就是直接取出步驟 2 中已經(jīng)存到指定內(nèi)存地址中的 offset。

回顧整個(gè)設(shè)計(jì)模型，左邊的指令流通過一個(gè)等效于完整 dmb 的 barrier 來保證 str offset 和 str bcp2 這兩條 str 指令的執(zhí)行順序并且全局可見；而右邊的指令流中，ldr bcp 和 ldr offset 這兩條 ldr 指令之間沒有任何 barrier，設(shè)計(jì)者可能認(rèn)為一個(gè)無條件跳轉(zhuǎn)指令可以為兩條 ldr 指令建立依賴，從而保證執(zhí)行順序，然而從實(shí)測(cè)結(jié)果來看是不成立的。

這里先來簡單補(bǔ)充介紹一下內(nèi)存順序模型的概念，現(xiàn)代 CPU 為了提高執(zhí)行效率，在指令的執(zhí)行順序上擁有很大的自主權(quán)，對(duì)每個(gè)獨(dú)立的 CPU 來說，只要確保語義不變，實(shí)際如何執(zhí)行都有可能，這種方式對(duì)于單個(gè) CPU 來說沒有問題，當(dāng)放到多個(gè) CPU 共享數(shù)據(jù)的時(shí)候，這種亂序執(zhí)行的行為就會(huì)引發(fā)每個(gè) CPU 看到數(shù)據(jù)的順序不一致問題，導(dǎo)致跨 CPU 的程序邏輯亂套了。這就需要對(duì)讀、寫內(nèi)存指令進(jìn)行約束，來規(guī)范每個(gè) CPU 看到的內(nèi)存生效行為，由此提出了內(nèi)存順序模型的概念：

其中 ARM 采用的是一種弱內(nèi)存模型，這種模型默認(rèn)對(duì)讀、寫指令沒有任何約束，需要由程序員自己通過插入 barrier 來手動(dòng)保證。

再回到這個(gè)問題上，測(cè)試方式是在 ldr offset 指令后額外加了檢測(cè)指令：

就是檢查 offset 值是否為 0，如果為 0 則直接強(qiáng)制 crash（設(shè)計(jì)上保證了 java 對(duì)象的任何實(shí)例字段的 offset 不可能是 0）。

經(jīng)過長時(shí)間測(cè)試，程序果然在這個(gè)位置觸發(fā)了 crash！這說明上面提到的兩條 ldr 指令不存在依賴關(guān)系，或者說這種依賴關(guān)系類似 ARMv8 手冊(cè)中描述的條件依賴，并不能保證執(zhí)行順序。ldr offset 指令先于 ldr bcp 執(zhí)行，使得讀到一個(gè)非法的 offset 值 0。更說明了，這才是這個(gè)案例的第一案發(fā)現(xiàn)場！

找到了問題的根因后，解決方法也就順利出爐了，那就是在兩條 ldr 指令之間插入 barrier 來確保這兩條 ldr 指令不發(fā)生亂序。實(shí)測(cè)證明，這種修復(fù)方案非常有效，這類 crash 現(xiàn)象消失。

詳細(xì)的修復(fù) patch 見 https://hg.openjdk.java.net/jdk/jdk/rev/b9529fcbbd33 。目前已經(jīng) backport 到 jdk8u292、jdk11.0.9、jdk15。

總結(jié)

Java 虛擬機(jī) (JVM) 為了追求性能，大量使用了無鎖編程進(jìn)行設(shè)計(jì)，而且這么多年以來 JDK（特別是 JDK8）主要都是面向 X86 平臺(tái)開發(fā)的，如今才慢慢的開始支持 aarch64 平臺(tái)，所以 aarch64 弱內(nèi)存序問題是我們面臨的一個(gè)比較嚴(yán)峻的挑戰(zhàn)。

后記

如果遇到相關(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/02/357miuol149.png">