DalvikVM优化的核心-解释器

DalvikVM的主要工作就是解释执行davik特有的java字节码-dex字节码，无疑，解释器就是dalvikVM的核心部分。事实上，我们用android自带系统工具监测caffeinmark（虚拟机测试程序）发现，解释器部分的调用占整个应用的90+%以上，再加上几个调用较多的小函数块，调用时间竟然占98%以上。尽管这部分的代码占整个dalvikVM代码很小的一部分，但这部分代码的能量确实大得惊人，dalvik的优化工作就是围绕它展开的。对解释器进行优化后，性能至少有50%的提升。

在android源码中，针对arm平台提供了好几种解释器的实现。其中包括标准的可移植型解释器和快速型解释器，这两种解释器的实现分别是C和汇编。从/dalvik/vm/dvm.mk中的内容可以知道，这两种解释会同时编译到libdvm.so中。Dalvikvm这个可执行文件对-dex进行处理时，会默认选择快速型解释器。当在做好的android文件系统/data/的位置增加一个文件local.prop（文件的内容为：dalvik.vm.execution-mode = int:portable）后，重启系统，通过测试dalvik性能我们就能发现dalvik的性能有明显的下降。这就可以确定默认的解释器是可移植型解释器了。

现在我们来分析一下DalvikVM的优化工作应该怎么进行。首先，我们最容易想到的就是将可移植型解释器全部用汇编实现。这条技术路线是可行的，但它的工作量有多大呢？标准型解释器的代码虽然不多，但将它们全部用汇编实现可不是那么容易的事情，这还不是最难的，最难的是怎么如何进行调试。将它们全部翻译成汇编后再调试？这个调试工作估计谁也不愿意去干。因此，必须编译出一个汇编、C混合实现的解释器，只要此技术路线拉通了，优化的工作就能按部就班的进行。再对汇编、C混合的比例加以控制，我们就可以每用汇编优化一条解释器指令实时地进行调试。此技术路线在6410开发板上顺利的拉通了，幸运的是，在非ARM架构的开发板上没有遇到新的问题，因此优化的进度一直在掌控之中。

当然，优化的过程不是一帆风顺。首先，非ARM架构的优化当然使用的是非ARM的汇编，在以ARM架构dalvikVM为参照时，为了表达相同的意思，就不得不绕过一些只针对ARM才有的汇编语句。毕竟，dalvikVM解释器的架构以及解释器指令实现的功能是确定的、与架构无关的。

其次，优化前期，寄存器的分配出现了小小的问题。dalvikVM是基于寄存器的。所谓的基于寄存器，其实就是用当前硬件环境下的若干个真实寄存器来用作固定的用途（当然，这若干个寄存器在使用前是要压栈保存的），如VM中的PC、FP等等。所以说，虽然VM中的PC、FP等都是模拟的，但每一个模拟的寄存器对应都一个真实的寄存器。这若干个寄存器在模拟VM中的寄存器时最好在一个头文件中规划好。说实话，dalvikVM还算不上是纯粹的基于寄存器的VM，毕竟每个解释器指令所带的操作数（不管是源操作数还是目的操作数，不管是“立即数”还是“寄存器”）都是存放在以FP（VM中的FP）为基址的堆栈中。若是硬件条件允许——有足够多的寄存器，dalvikVM的性能将会再上一个台阶。足够多的寄存器肯定是奢望，但是比ARM多几个寄存器的芯片还是有的，比如某款国产CPU就拥有32个寄存器之多，若是加以利用，效果可想而知。