赛博考古之Dalvik虚拟机
https://zhuanlan.zhihu.com/p/717078351
赛博考古之Dalvik虚拟机
彼岸归航
彼岸归航
纸上得来终觉浅
关注
55 人赞同了该文章
最近想了解一下Android的虚拟机,但是网上没有太多很好的资料(明明是那么出名的一个系统...)。在网上翻到了Google在Google I/O 2008介绍Android的初代虚拟机dalvik的视频,我就来次赛博考古,写篇小文章介绍一下一代神机dalvik。
dalvik设计初衷
dalvik最初是被设计在性能极度有限的初代手机上运行的: - 较慢的CPU - 极其有限的内存(总共64MB,运行系统服务后可用大概10MB) - 缺少swap空间
尽管Android被设计为运行java程序,但java将每个类都编译为单独的.class文件,有一些信息(如版本字符串等)会在多个.class中重复。为了减少文件体积,降低重复。Google选择将多个.class文件整合为一个dex文件,作为dalvik上的执行文件。将多个类合并可以整合各个类中的重复部分。Google的测试表明,相较原本的.class文件,jar(压缩的.class文件)大小为原来的约50%,而dex文件为原来的约45%。
节约可用内存 -> Zygote
dalvik的设计背景中,留给应用程序的可用内存只有10MB,而且几乎没有swap空间,这下swap机制也不管用了。
Google设计人员将内存分为四类: - clean vs dirty - clean:mmap()ed 且没有被写过 - dirty:malloc()ed - shared vs private - shared: 被多个进程共享 - private:只被一个进程使用
优化内存时可以不用考虑clean内存,不管是shared还是private。因为clean内存有文件作为它的备份,内存不足时可以放心释放。
dirty内存是重点考虑的对象。之前提到过几乎没有swap空间,dirty内存必须驻留在内存里。最坏的情况是private dirty。如果所有进程都使用一定量private dirty内存,内存空间会很快耗尽。shared dirty空间可以减少内存使用量。堆是一个典型的dirty区域,且是private的。能否将堆变成shared的呢?Google设计人员基于这样的观察:应用程序很少写堆,也就是说堆几乎是只读的。一个神奇的机制在共享“几乎只读”的区域上有完美的性能表现,即Copy on write(COW)。所以,便催生了Zygote进程。
Zygote进程预先有一个堆和加载好的大量常用类。Android上的其他所有进程都由Zygote fork()自身而来。这样所有进程就相当于共享了同一个堆和大量的常用类。只有当进程实际写堆时,系统才会分配一小块内存给它,避免了浪费。且节约了常用类加载需要的时间和存储需要的空间。进程就相当于从受精卵(zygote)中“孵化”出来。不愧是天才设计。
快速GC -> separated meta data
对象用于GC的meta data既可以跟对象的数据放在一起,也可以与对象数据分离,单独放在一块位置。dalvik虚拟机选择分离meta data。因为GC需要遍历对象meta data。这样做可以提高cache 命中率。
在低性能机器上高效工作 -> Register Machine
传统的JVM是stack machine,即基于栈的虚拟机。dalvik是register machine,即基于寄存器的虚拟机。stack machine假设栈的大小无限,使用一个或多个栈来存储数据和中间结果,操作数(operands)被压入栈中,指令从栈中弹出操作数并进行计算,结果再被压回栈中。register machine假设有无限个可用的寄存器,计算直接在寄存器中进行。不同的虚拟机结构也意味着dalvik运行的bytecode和JVM是不一样的。事实上,dex文件中的byte code是dalvik自己的bytecode,称为dalvik bytecode,而不是JVM bytecode。
具体的设计可以参见https://source.android.com/devices/tech/dalvik/dalvik-bytecode
虽然stack machine的假设简单,但是很可能引入一些不必要的内存访问。在低性能的android手机上,Google认为采用register machine有如下优势: - 避免指令分发(instruction dispatch) - 避免不必要的内存访问 - 更高效地处理指令 - 每条指令有更高的语义密度(个人认为即表达语义更精炼的意思)
Google测试得到register machine相比stack machine减少了指令使用数量,但是增加了指令流的长度。
提高应用的速度 -> Install time work
因为CPU的性能很差,Google希望尽可能减少应用运行时的CPU工作,而是尝试提前进行。具体提前的时机,就是在应用安装的时候。
在应用安装时,dalvik预先对应用进行验证(verify)和优化(optimize)。
优化工作主要是静态链接,内联一些特殊的native函数等等。
值得注意的是这时候Google还说没有必要加入JIT(甚至专门做了一张ppt表示NO JIT)。给出的理由是JIT无关紧要,且编译出来的大量Native code会占用空间。并且认为Google提供的系统库已经接管了最需要性能的部分,如2/3D绘图和媒体,没有必要将用户代码也编译为native。当然我们知道后来的dalvik还是加上了JIT,甚至dalvik的后继者ART做得更加极端,直接上了AOT。不过尽可能将工作提前进行的优化方式还是没有变。
参考资料
【Google I_O 2008 - Dalvik Virtual Machine Internals】
dex bytecode设计参考资料:
https://source.android.com/devices/tech/dalvik/dalvik-bytecode
https://source.android.com/devices/tech/dalvik/instruction-formats.html