ART虚拟机method tracing技术解析
一、method tracing介绍
概述
这个是谷歌提供的对java的函数级trace工具，和systrace只支持打点不同，method tracing能支持到函数，看到具体的函数执行时间，准确的分析出来执行的时间短板。
1.生成trace的方式
sampling方式：
sampling方式采用sample任务，定期抓取各个线程的调用栈，采集精度和采集的频次正相关，同时由于java stack采集的时候需要做suspend，因此还是有一部分的效率损失。
我们可以看到，原生单次采集使用的是suspendall，而不是对threadlist上的线程逐个做getStackTrace，因此效率损失会比较严重。
trace方式：
通过在执行流程插入enter-exit来观测：
相比于sample 方式，trace可以准确的获取到每个函数的进入和退出时间，精度可以非常高。
由于art虚拟机执行特点，这个方案相较于sample方式复杂度要高不少，下文会着重介绍trace方式的实现原理
2.trace启动流程
我们从trace方式的启动入口开始看起
几个关键的流程分别是
1.停用掉JIT GC，这个是防止stub方式替换之后，因为JIT GC引起的重新指定执行方式，释放JIT code和entry之间存在竞争。
2.进行suspend all，这是因为后续真正开启trace的时候，会对所有的函数入口做重新指定，必然要对整个java世界进行停顿，保证安全性。
3.注册listener
然后进入EnableMethodTracing，真正发起tracing的核心流程。
根据是否要回切解释执行，有两种不同的处理方式。
具体内部流程有两个关键的处理：
1.构造一个InstallStubsClassVisitor，这个的作用是遍历所有类，然后对每个类做执行方法入口的重定向，也就是stub回填。
2.对各个线程的当前栈做一下处理，主要是植入exit frame。为什么exit point要单独处理，我们后文详细介绍，这个地方谷歌采用了一个非常trick的方式。
接下来我们继续看InstallStubsClassVisitor遍历class替换入口的处理：
真正的核心处理流程其实是下述：
如果是解释执行方式，则把入口都换成GetQuickToInterpreterBridge
如果是stub方式，则换成了GetQuickInstrumentationEntryPoint
3.trace采集的分类
从前面的代码流程中，我们能发现，分成了两个类型。
采集的方式分类
interpretor only：这是最简单粗暴的方式，直接强制整个系统回退到解释执行。
stubs方式：这个方式是希望提升tracing开启之后的性能表现，因此在支持解释执行的基础上，对JIT和AOT的函数，也做了特殊处理进行支持，而不需要强制回退到解释执行。相比纯解释执行，这部分的技术细节更丰富，使用了一些“奇技淫巧”，本文后续着重介绍stub对JIT和AOT支持的方式。
trace执行主要是在函数进出的地方植入enter-exit对来实现对函数执行流程的打点。
因为要在一个java 方法的入口和出口植入事件的记录，所以trace的实现就和虚拟机的执行方式强相关，我们先简单介绍下虚拟机的几种执行方式。
虚拟机的执行方式
解释执行：解释执行ART能够全程介入java函数的执行，这就包括了函数的入栈和出栈，因此设置观测点非常容易，直接在虚拟机执行流程中增加enter/exit埋点即可。
JIT：经过JIT编译的dex code其实target已经是asm了，这个时候的java函数调用和arm64的native函数是非常类似的。
AOT：同JIT，区别在AOT是提前构建而JIT是运行时构建的。
我们看到启动阶段的实现，是直接插入了enter，那真正的函数入口是怎么路由处理的，这里面其实由于虚拟机设计的特殊性，直接插入wrapper有一些问题，具体的下文先补充一些虚拟机的相关知识，然后结合这些背景知识慢慢道来。
二、背景补充
要知道enter和exit的具体植入和运行原理，我们先补充一点art虚拟机的知识。
1.java函数入口
每个java方法，在虚拟机层面都维持着一个ArtMethod数据结构，每次调用一个方法，实际上是通过ArtMethod找到真正的入口，然后进行调用的。
java动态性的方式也是通过：
object->class->art method ->entrypoint来实现的
我们每次对一个对象call function，实际上就是找到对象的类型，类型里面回填了真正的artmethod，然后查找到正确的入口。
这个布局我们在看替换stub的整体流程的时候就发现了，替换stub就是沿着遍历class-遍历method的方式来完成的执行入口重定向。
在只有一个入口可以插入的情况下，我们很容易想到做一个wrapper，在wrapper中调用art_method同时完成跟踪：
图示中的stack frame 1 2 3就是对应了我们栈上的栈帧，可以看到如果要使用wrapper方式，会在caller和真正的执行函数之间引入一个新的wrapper栈帧，我们结合下面一个点，就会发现问题。
2.walkstack
在anr，抛出异常的时候，都会对java调用栈进行遍历，此种遍历的逻辑主要在walkstack中完成的，这个如果加入了wrapper，会导致穿透的情况变得复杂如下图：
这种栈结构要兼容起来就非常的痛苦，在已有的JNI-解释，JNI-quick，quik-quik，quik-解释之上每种都要考虑栈内有wrapper的场景。
总结
通过上述的虚拟机的特征有如下两个问题：
1.art_method的入口只有一个挂载点，JIT和AOT处理后的java函数调用方式也并不能提供exit事件的记录时机。
2.最好不要导致stack结构发生变化，否则在进行栈遍历的时候会带来非常大的兼容负担。
1和2看似是矛盾的，因为常规的手段，只有一个函数入口的话，需要使用wrapper，但是如果使用wrapper函数，栈结构就会发生改变。这个矛盾android使用了一个非常巧妙的方法解决，我们下文就对stub的解决方法做个详细的介绍。
三、stub技术原理探究
因为jit和odex执行的对象实际上都是汇编，我们在汇编中调用一个函数，实际上只能insert一个entrypoint，那出栈如何实现呢？
此处其实就是使用了arm64的calling conversion偷鸡，我们先看下替换的函数art_quick_instrumentation_entry，这个函数是纯汇编写的，我们看下汇编的核心处理：
汇编中使用bl指令调用了artInstrumentationMethodEntryFromCode（BL指令在函数结束后，ret会回到此处，而BR则是直接基于当前的contexts做跳转，ret后就回到caller了），在artInstrumentationMethodEntryFromCode中主要做了三个事情
1.抓取并且查询到了真实java函数的入口地址
2.记录enter事件
3.记录返回地址的PC(LR寄存器)
artInstrumentationMethodEntryFromCode通过x0把真正java方法的入口返回，然后art_quick_instrumentation_entry做了如下两个事情：
1.把x30设置为art_quick_instrumentation_exit的入口地址（adr x30, 0x21a6a0）
2.通过BR跳转到获取的java方法入口（br x16）
这样，在真正的被调函数完成之后ret，就会定向到exit的汇编上下文中：
在exit函数里面
1.记录了出栈事件
2.还原了caller PC
通过改写栈上位置（str x0, [sp, #504]），然后restore的时候（ldp x29, x30, [sp, #496]），就自然读到目标lr了，同时这样不会有寄存器污染的问题
还原lr之后，直接使用br指令跳转到caller原始的位置。
以上就是android利用arm callingconversion实现的exit植入。
总结
如下图所示，android通过篡改调用前的lr，结合BL和BR指令的不同ret方式，完成了单入口，在破坏栈结构的情况下，记录了enter和exit事件对。
四、安卓最新的演进
1.演进概述
因为复杂度和对jit的冲突，导致了不太好
目前谷歌在最新的安卓版本做出了重大的更新：
1.关闭了对odex的支持
2.在jit code生成的时候，如果开启了tracing，会生成出带有enter和exit的code，直接在code gen层面支持。
3.对于stub方式，不做全量的替换，使能trace的时候整个系统回退到解释执行，然后清理jit cache，新的jit函数会直接生成带有enter和exit的code
2.谷歌最新变更相关合入：
1.jit code中直接生成enter/exit hook调用
https://cs.android.com/android/_/android/platform/art/+/5097f83c4719a76fdfab1044ab745273841aca45
2.instrument替换掉trace odex的支持
https://cs.android.com/android/_/android/platform/art/+/890b19bd625be5d0e4a876e3eb11b8b893fb0c13
相关引用
method trace概述/举例：https://juejin.cn/post/7107137302043820039
谷歌method trace介绍：https://developer.android.com/studio/profile/generate-trace-logs?hl=zh-cn
审核编辑：汤梓红
-
谷歌
+关注
关注
27文章
6161浏览量
105295 -
函数
+关注
关注
3文章
4327浏览量
62567 -
Method
+关注
关注
0文章
9浏览量
7257 -
虚拟机
+关注
关注
1文章
914浏览量
28158 -
ART
+关注
关注
0文章
26浏览量
10482
原文标题：ART虚拟机method tracing技术解析
文章出处：【微信号：LinuxDev，微信公众号：Linux阅码场】欢迎添加关注！文章转载请注明出处。
发布评论请先 登录
相关推荐
什么是虚拟机？虚拟机真的那么好用吗？
什么是区块链虚拟机和普通虚拟机有啥区别
KVM虚拟机管理和基本使用
反虚拟机技术合集1
反虚拟机技术合集2
反虚拟机技术合集3
反虚拟机技术合集4
工商网监
评论