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有一些问题，具体的下文先补充一些虚拟机的相关知识，然后结合这些背景知识慢慢道来。

  资料直通车：Linux内核源码技术学习路线+视频教程内核源码

学习直通车：Linux内核源码内存调优文件系统进程管理设备驱动/网络协议栈

二、背景补充

要知道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事件对。

原文作者：内核工匠