Dalvik——tests工具学习文档

1 测试工具的实现
1.1 调研目的
    目前正在进行针对Unicore架构的Dalvik虚拟机改写，为了保证整个Android操作系统在Unicore上的正常运行，我们试图先独立测试改写后的Dalvik虚拟机；而Android2.1源码中包含了dalvik虚拟机的测试工具，其目录位于/android2.1/dalvik/tests下，我们先对它进行调研，看能否用它来测试我们改写后的dalvik虚拟机。
    调研分为三部分进行，首先了解该测试工具的实现方式，其次介绍它的使用方法，最后评估用它测试修改后的dalvik虚拟机的可行性。
1.2 tests简介
首先分析/android2.1/dalvik/tests目录的结构：
-tests dalvik测试工具和测试代码文件夹。
--001——078   文件夹，保存了78个测试代码，主要由/src/*.java（测试所需代码）
以及xpected.txt（测试期望结果文档）和info.txt（测试说明文档）；
--ect     试工具的最终实现脚本，用Linux shell命令格式写成；
--run-all-tests   执行文件，测试所有78个测试代码；
--run-test   可执行文件，指定参数来测试特定的测试代码。

1.3 测试工具的实现
    通过上节的介绍，要理解测试工具是如何实现对dalvik虚拟机的测试，就必须理解run-test可执行文件（run-all-tests可以看做是逐一调用run-tests），下面将具体介绍该可执行文件的实现方式。
1.3.1 run-test的参数
1.3.1.1 综述
    进入/android2.1/dalvik/tests，在Linux shell下输入命令：
./run-test –help
    可以出现使用帮助，罗列并解释如下：
run-test –help        打印帮助信息
run-test [options] [test-name]    正常运行命令的格式
run-test --dev [options] [test-name]    开发模式（运行结果dump到stdout）
run-test --update [options] [test-name] 更新模式（运行结果代替expect.txt）
运行参数：
--fast    使用快速解释器（默认）
   -jit     使用JIT
   --portable   使用可移植的解释器
   --debug    等待调试器的连接
   --no-verify   关闭校对功能（默认打开）
   --no-optimize     关闭代码优化功能（默认打开）
   --no-precise   关闭精确GC功能（默认打开）
   --zygote    从Zygote进程创建当前进程，如果使用，当前运行参数会被忽视
--local    使用主机-本地（host-local）模拟器
--valgrind    本地运行时使用内存监测
--reference   使用主机-本地参考（host-local reference）模拟器

    通过帮助信息我们了解到，run-test有正常模式、开发模式、更新模式三种模式和多种参数，下面对参数的含义进行更详细的说明，并评估了该参数对于我们使用本测试工具的价值，在下文中我们根据需要进一步调研一部分参数：
参数                                                含义                                                                              价值
fast                              dalvik的解释器采用快速解释器，与可移植型解释器相对                     高
jit                                  android2.2开始采用的jit技术                                                               低
portable                       dalvik解释器采用可移植型解释器，与快速解释器相对                         高
debug                         调试用，等待调试器连接                                                                     高
verify                          dexopt的校对模式，dexopt用于dex代码的优化                                    中
optimize                       dexopt的优化模式                                                                                中
precise                        GC管理的一个选项                                                                              低
zygote                         直接从Zygote进程创建测试进程                                                          中
local                             使用local设备（不是host上的虚拟机）来测试                                     高
valgrind                       --local并且添加了内存管理的东西                                                        低
reference                    可使用host上的模拟器，模拟local设备的虚拟机进行测试                    高

1.3.1.2 debug
        该参数的帮助文档是：等待调试器的连接（wait for debugger to attach）。为了使用该参数必须实现android的调试器（Debugger），dalvik虚拟机支持许多开发环境下的源码级的调试，任何基于JDWP（Java Debug Wire Protocol）的远程调试工具都可以，包括JDB、Eclipse、JSwat等。
        首先，介绍该参数的实现原理。在本测试的脚本文件/android2.1/dalvik/tests/ect/push-and-run-test-jar（下文将解释为什么是这个）中可以看出，debug参数是通过以下命令才实现的：
代码位置：/android2.1/dalvik/tests/ect/push-and-run-test-jar
源代码：
调试参数设定：
if [ "$DEBUG" = "y" ]; then
    DEX_DEBUG="-agentlib:jdwp=transport=dt_android_adb,server=y,suspend=y"
fi
执行命令：
adb shell cd /data \; dalvikvm $DEX_VERIFY $DEX_OPTIMIZE $DEX_DEBUG \
$GC_OPTS -cp test.jar "-Xint:${INTERP}" -ea Main "$@"
参数解释如下：
transport： 所使用的传输机制，dalvik支持TCP/IP socket、通过adb（dt_android_adb）访
问USB的方式；
server：   决定虚拟机是作为服务器（server）还是客户端（client），作为服务器时，虚拟机等待调试器连接，反之，虚拟机主动试图连接调试器；
suspend： 如果是y，虚拟机在调试器连接之前不运行任何代码，连接时，它会告诉调试器它挂起了，直到有新的指令它才会运行。
    最终--debug的参数变为dalvikvm可执行文件的参���来执行。至于JDWP的工作原理，在此不展开讨论。
下面，介绍--debug参数的具体使用方法（以在Linux下运行android模拟器、执行本测试方法第17号源码为例进行介绍）。
1、在本地Linux环境启动android模拟器
cd /android2.1/out/host/linux-x86/bin （添加了环境变量后就可以在任意目录输入emulator）
emulator
2、运行本测试工具
cd /android2.1/dalvik/tests
./run-test --debug 017
此时在shell下将显示如下内容：
[seucr@android2 tests]$ ./run-test --debug 017-float/
/home/seucr/android2.1_r2/dalvik/tests/017-float: running...
（等待调试器连接）
3、运行DDMS
DDMS（Dalvik Debug Monitor Server）可以看做连接设备和JDWP调试器的桥梁，它显示设备当前的进程、方法等内容，允许向设备发送命令，调试器可以通过它看到设备底层的PID号、进程号等内容。
cd /android2.1/out/host/linux-x86/bin
ddms
此时在DDMS界面上可以看到当前模拟器的运行状态。由于此时已经在运行debug下的测试，因此在DDMS上可以看到一个进程名叫“？”，点击它。
4、运行JDB调试
jdb -attach localhost:8700
此时shell会显示如下内容：
[seucr@android2 bin]$ jdb -attach localhost:8700
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
>
VM Started: "thread=<3> main", dalvik.system.NativeStart.main(), line=-1 bci=-1
<3> main[1]
此时就已经进入了调试界面，通过help命令可以看到可执行的命令，包括run、step、stepi等很多。直接运行run可以跑完测试程序。
5、结果分析
最终的结果很有可能是测试FAILED（判断依据下文将详细叙述）。这是因为在执行build时前期会导致：
DDM dispatch reg wait timeout
Can't dispatch DDM chunk 52454151: no handler defined
错误，后来就可以正常运行，具体原因不详。但是对比expect.txt和output.txt，可以看出期望的结果已经运行出来了。