一、method tracing介紹

概述

這個(gè)是谷歌提供的對(duì)java的函數(shù)級(jí)trace工具，和systrace只支持打點(diǎn)不同，method tracing能支持到函數(shù)，看到具體的函數(shù)執(zhí)行時(shí)間，準(zhǔn)確的分析出來執(zhí)行的時(shí)間短板。

1.生成trace的方式

sampling方式：

sampling方式采用sample任務(wù)，定期抓取各個(gè)線程的調(diào)用棧，采集精度和采集的頻次正相關(guān)，同時(shí)由于java stack采集的時(shí)候需要做suspend，因此還是有一部分的效率損失。

我們可以看到，原生單次采集使用的是suspendall，而不是對(duì)threadlist上的線程逐個(gè)做getStackTrace，因此效率損失會(huì)比較嚴(yán)重。

trace方式：

通過在執(zhí)行流程插入enter-exit來觀測(cè)：

相比于sample 方式，trace可以準(zhǔn)確的獲取到每個(gè)函數(shù)的進(jìn)入和退出時(shí)間，精度可以非常高。

由于art虛擬機(jī)執(zhí)行特點(diǎn)，這個(gè)方案相較于sample方式復(fù)雜度要高不少，下文會(huì)著重介紹trace方式的實(shí)現(xiàn)原理

2.trace啟動(dòng)流程

我們從trace方式的啟動(dòng)入口開始看起

幾個(gè)關(guān)鍵的流程分別是

1.停用掉JIT GC，這個(gè)是防止stub方式替換之后，因?yàn)镴IT GC引起的重新指定執(zhí)行方式，釋放JIT code和entry之間存在競(jìng)爭(zhēng)。

2.進(jìn)行suspend all，這是因?yàn)楹罄m(xù)真正開啟trace的時(shí)候，會(huì)對(duì)所有的函數(shù)入口做重新指定，必然要對(duì)整個(gè)java世界進(jìn)行停頓，保證安全性。

3.注冊(cè)listener

然后進(jìn)入EnableMethodTracing，真正發(fā)起tracing的核心流程。

根據(jù)是否要回切解釋執(zhí)行，有兩種不同的處理方式。

具體內(nèi)部流程有兩個(gè)關(guān)鍵的處理：

1.構(gòu)造一個(gè)InstallStubsClassVisitor，這個(gè)的作用是遍歷所有類，然后對(duì)每個(gè)類做執(zhí)行方法入口的重定向，也就是stub回填。

2.對(duì)各個(gè)線程的當(dāng)前棧做一下處理，主要是植入exit frame。為什么exit point要單獨(dú)處理，我們后文詳細(xì)介紹，這個(gè)地方谷歌采用了一個(gè)非常trick的方式。

接下來我們繼續(xù)看InstallStubsClassVisitor遍歷class替換入口的處理：

真正的核心處理流程其實(shí)是下述：

如果是解釋執(zhí)行方式，則把入口都換成GetQuickToInterpreterBridge

如果是stub方式，則換成了GetQuickInstrumentationEntryPoint

3.trace采集的分類

從前面的代碼流程中，我們能發(fā)現(xiàn)，分成了兩個(gè)類型。

采集的方式分類

interpretor only：這是最簡(jiǎn)單粗暴的方式，直接強(qiáng)制整個(gè)系統(tǒng)回退到解釋執(zhí)行。

stubs方式：這個(gè)方式是希望提升tracing開啟之后的性能表現(xiàn)，因此在支持解釋執(zhí)行的基礎(chǔ)上，對(duì)JIT和AOT的函數(shù)，也做了特殊處理進(jìn)行支持，而不需要強(qiáng)制回退到解釋執(zhí)行。相比純解釋執(zhí)行，這部分的技術(shù)細(xì)節(jié)更豐富，使用了一些“奇技淫巧”，本文后續(xù)著重介紹stub對(duì)JIT和AOT支持的方式。

trace執(zhí)行主要是在函數(shù)進(jìn)出的地方植入enter-exit對(duì)來實(shí)現(xiàn)對(duì)函數(shù)執(zhí)行流程的打點(diǎn)。

因?yàn)橐谝粋€(gè)java 方法的入口和出口植入事件的記錄，所以trace的實(shí)現(xiàn)就和虛擬機(jī)的執(zhí)行方式強(qiáng)相關(guān)，我們先簡(jiǎn)單介紹下虛擬機(jī)的幾種執(zhí)行方式。

虛擬機(jī)的執(zhí)行方式

解釋執(zhí)行：解釋執(zhí)行ART能夠全程介入java函數(shù)的執(zhí)行，這就包括了函數(shù)的入棧和出棧，因此設(shè)置觀測(cè)點(diǎn)非常容易，直接在虛擬機(jī)執(zhí)行流程中增加enter/exit埋點(diǎn)即可。

JIT：經(jīng)過JIT編譯的dex code其實(shí)target已經(jīng)是asm了，這個(gè)時(shí)候的java函數(shù)調(diào)用和arm64的native函數(shù)是非常類似的。

AOT：同JIT，區(qū)別在AOT是提前構(gòu)建而JIT是運(yùn)行時(shí)構(gòu)建的。

我們看到啟動(dòng)階段的實(shí)現(xiàn)，是直接插入了enter，那真正的函數(shù)入口是怎么路由處理的，這里面其實(shí)由于虛擬機(jī)設(shè)計(jì)的特殊性，直接插入wrapper有一些問題，具體的下文先補(bǔ)充一些虛擬機(jī)的相關(guān)知識(shí)，然后結(jié)合這些背景知識(shí)慢慢道來。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ?

二、背景補(bǔ)充

要知道enter和exit的具體植入和運(yùn)行原理，我們先補(bǔ)充一點(diǎn)art虛擬機(jī)的知識(shí)。

1.java函數(shù)入口

每個(gè)java方法，在虛擬機(jī)層面都維持著一個(gè)ArtMethod數(shù)據(jù)結(jié)構(gòu)，每次調(diào)用一個(gè)方法，實(shí)際上是通過ArtMethod找到真正的入口，然后進(jìn)行調(diào)用的。

java動(dòng)態(tài)性的方式也是通過：

object->class->art method ->entrypoint來實(shí)現(xiàn)的

我們每次對(duì)一個(gè)對(duì)象call function，實(shí)際上就是找到對(duì)象的類型，類型里面回填了真正的artmethod，然后查找到正確的入口。

這個(gè)布局我們?cè)诳刺鎿Qstub的整體流程的時(shí)候就發(fā)現(xiàn)了，替換stub就是沿著遍歷class-遍歷method的方式來完成的執(zhí)行入口重定向。

在只有一個(gè)入口可以插入的情況下，我們很容易想到做一個(gè)wrapper，在wrapper中調(diào)用art_method同時(shí)完成跟蹤：

圖示中的stack frame 1 2 3就是對(duì)應(yīng)了我們棧上的棧幀，可以看到如果要使用wrapper方式，會(huì)在caller和真正的執(zhí)行函數(shù)之間引入一個(gè)新的wrapper棧幀，我們結(jié)合下面一個(gè)點(diǎn)，就會(huì)發(fā)現(xiàn)問題。

?

2.walkstack

在anr，拋出異常的時(shí)候，都會(huì)對(duì)java調(diào)用棧進(jìn)行遍歷，此種遍歷的邏輯主要在walkstack中完成的，這個(gè)如果加入了wrapper，會(huì)導(dǎo)致穿透的情況變得復(fù)雜如下圖：

這種棧結(jié)構(gòu)要兼容起來就非常的痛苦，在已有的JNI-解釋，JNI-quick，quik-quik，quik-解釋之上每種都要考慮棧內(nèi)有wrapper的場(chǎng)景。

總結(jié)

通過上述的虛擬機(jī)的特征有如下兩個(gè)問題：

1.art_method的入口只有一個(gè)掛載點(diǎn)，JIT和AOT處理后的java函數(shù)調(diào)用方式也并不能提供exit事件的記錄時(shí)機(jī)。

2.最好不要導(dǎo)致stack結(jié)構(gòu)發(fā)生變化，否則在進(jìn)行棧遍歷的時(shí)候會(huì)帶來非常大的兼容負(fù)擔(dān)。

1和2看似是矛盾的，因?yàn)槌Ｒ?guī)的手段，只有一個(gè)函數(shù)入口的話，需要使用wrapper，但是如果使用wrapper函數(shù)，棧結(jié)構(gòu)就會(huì)發(fā)生改變。這個(gè)矛盾android使用了一個(gè)非常巧妙的方法解決，我們下文就對(duì)stub的解決方法做個(gè)詳細(xì)的介紹。

三、stub技術(shù)原理探究

因?yàn)閖it和odex執(zhí)行的對(duì)象實(shí)際上都是匯編，我們?cè)趨R編中調(diào)用一個(gè)函數(shù)，實(shí)際上只能insert一個(gè)entrypoint，那出棧如何實(shí)現(xiàn)呢？

此處其實(shí)就是使用了arm64的calling conversion偷雞，我們先看下替換的函數(shù)art_quick_instrumentation_entry，這個(gè)函數(shù)是純匯編寫的，我們看下匯編的核心處理：

匯編中使用bl指令調(diào)用了artInstrumentationMethodEntryFromCode（BL指令在函數(shù)結(jié)束后，ret會(huì)回到此處，而BR則是直接基于當(dāng)前的contexts做跳轉(zhuǎn)，ret后就回到caller了），在artInstrumentationMethodEntryFromCode中主要做了三個(gè)事情

1.抓取并且查詢到了真實(shí)java函數(shù)的入口地址

2.記錄enter事件

3.記錄返回地址的PC(LR寄存器)

artInstrumentationMethodEntryFromCode通過x0把真正java方法的入口返回，然后art_quick_instrumentation_entry做了如下兩個(gè)事情：

1.把x30設(shè)置為art_quick_instrumentation_exit的入口地址（adr? ? ?x30, 0x21a6a0）

2.通過BR跳轉(zhuǎn)到獲取的java方法入口（?br? ? ? x16）

這樣，在真正的被調(diào)函數(shù)完成之后ret，就會(huì)定向到exit的匯編上下文中：

在exit函數(shù)里面

1.記錄了出棧事件

2.還原了caller PC

通過改寫棧上位置（str? ? ?x0, [sp, #504]），然后restore的時(shí)候（?ldp? ? ?x29, x30, [sp, #496]），就自然讀到目標(biāo)lr了，同時(shí)這樣不會(huì)有寄存器污染的問題

還原lr之后，直接使用br指令跳轉(zhuǎn)到caller原始的位置。

以上就是android利用arm callingconversion實(shí)現(xiàn)的exit植入。

總結(jié)

如下圖所示，android通過篡改調(diào)用前的lr，結(jié)合BL和BR指令的不同ret方式，完成了單入口，在破壞棧結(jié)構(gòu)的情況下，記錄了enter和exit事件對(duì)。

?

四、安卓最新的演進(jìn)

1.演進(jìn)概述

因?yàn)閺?fù)雜度和對(duì)jit的沖突，導(dǎo)致了不太好

目前谷歌在最新的安卓版本做出了重大的更新：

1.關(guān)閉了對(duì)odex的支持

2.在jit code生成的時(shí)候，如果開啟了tracing，會(huì)生成出帶有enter和exit的code，直接在code gen層面支持。

3.對(duì)于stub方式，不做全量的替換，使能trace的時(shí)候整個(gè)系統(tǒng)回退到解釋執(zhí)行，然后清理jit cache，新的jit函數(shù)會(huì)直接生成帶有enter和exit的code

2.谷歌最新變更相關(guān)合入：

1.jit code中直接生成enter/exit hook調(diào)用

https://cs.android.com/android/_/android/platform/art/+/5097f83c4719a76fdfab1044ab745273841aca45

?

2.instrument替換掉trace odex的支持

https://cs.android.com/android/_/android/platform/art/+/890b19bd625be5d0e4a876e3eb11b8b893fb0c13??

原文作者：內(nèi)核工匠