注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

钱五哥の163空间

记录俺的生活和工作历程

 
 
 

日志

 
 
关于我

从事网络通信软件和开发管理开发多年,了解各类软件系统的架构、设计、开发和测试以及相应的开发方法。工作之余,喜欢研究一些自己感兴趣的事情,包括写写小程序、做做木工、看看连续剧、读读军事杂志、养鱼种花等等

网易考拉推荐

Dalvik VM和JVM的一个比较  

2012-09-02 04:00:50|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

由于JVM的GC一直是个问题,因此被问到为什么不能用Davik VM来代替JVM,原因是Dalvik VM被看做是Android上的“神器”,支撑了所有Android。多花了一些时间来研究了一下Dalvik VM的情况,发现情况还是很有意思的。

首先Dalvik VM主要提供了Android应用执行环境框架和应用(下图蓝色部分),而内核和关键Lib都是C/C++语言实现的,包括显示、数据库、libc、认证、字体等经常被使用到的模块,也是最影响到性能的部分。

image

其次,Dalvik VM确实做了大量的优化,包括如下方面:

(1)Dex文件镜像格式采用了内容压缩技术。将多个class中的内容统一归类存储,即将方法、属性、字符串、类型均抽取出来统一存放,这样可以使所有重复的内容仅出现一次,通过引用(id)来访问。这种技术比JVM中基于zip的压缩技术更高。虽然压缩后的大小差不多,但是内容压缩无需解压缩,因此可以有效减少程序的启动时间

(2)用Zygote统一管理VM。Android中没有应用均对应了一个VM,但是这些VM和JVM的使用方式不同,这些VM共享了应用程序中的系统代码和数据,这就类似OS中的动态Lib管理那样,同样的内容仅被加载一次,而一旦系统数据需要被某个应用修改时,则采用Copy-On-Write技术保证最少的性能开销。这种技术不会造成Windows中的“Dll Hell”问题,因为系统库均为Dalvik提供,不会存在版本问题。但是随着应用的发展,可能会逐步出现可重用的Lib,那个时候就会有Windows曾经面临的痛苦了。

(3)Register-based VM。这个和JVM这种Stack-based VM有较大的不同。后者基于堆栈执行程序,虽然每个指令字较短,但是指令执行时却通常需要加载数据到堆栈,这就带来了更多的内存访问和更多的指令。虽然由于指令字较短,最终的程序文件大小并不比基于寄存器的程序更大。而基于寄存器的VM通常指令字较长,但是操作数通常在寄存器中,这样就提高了执行的速度。Dan Bornstein在2008年的演讲中给出如下数据,基于寄存器的Dalvik VM比基于Stack的JVM:

? 30% fewer instructions
? 35% fewer code units
? 35% more bytes in the instruction stream

但是这并不代表JVM没有优化潜力,Oracle在2010年11月发布了Java SE 嵌入式版本对比Android JIT 2.2版本,性能超过Dalvik2~3倍。从文后的评论中可以看出多数人民群众的共识是Dalvik落后于JVM很多,以后CPU核数越多,差距可能越是明显,但是大家对于Oracle无力推出Android的JVM,表示很无奈。

image007.png

那么是否JVM就此采用了基于寄存器的实现呢?我想应该是否定的。但是目前的趋势是基于堆栈和寄存器的

最后就是关于GC。其实从上面的对比中已经可以看到JVM的先进性,这在GC方面也是如此。JVM有多种GC收集器:

  • Serial Collector
  • Parallel Collector/Parallel Compacting Collector/Throughput Collector
  • Concurrent Mark-Sweep (CMS) Collector/Low Latency Collector

目前适用于低延迟的服务器端Java的收集器主要并行标记和收集器CMS,特点是对于旧生代数据的收集采用了多线程并发、两轮次标记等“聪明”的收集方式,这样可以缩短并行收集器在旧生代上的高延迟。但是CMS的缺点是不做compact,这样会带来后续较多的内存碎片,从而影响性能。

image

Dalvik GC的介绍不多,需要了解最新动态只能研究源代码。某人在2009年的研究表明,Dalvik GC采用了串行的MarkSweep,没有Generation,没有周期性扫描,没有compact,都是Stop-The-World GC,延迟通常超过100ms,在成熟度方面很低,被认为是“赶出来的”。2011年Google介绍了Gingerbread GC,这个GC先进:些多数情况下是并发的GC,局部收集,延迟小于5ms。

?

因此就可以问一个很符合逻辑的问题,能不能用Dalvik VM取代JVM,用于Hadoop、HBase等系统?现在的答案是No

(1)Dalvik VM是32bits系统,无法直接在64bits的Linux上面使用 - 即使有人在Linux上交叉编译了Dalvik VM。

(2)Davik VM面向客户端应用优化,GC方面不成熟,通常适用于几百MB的手机系统。

(3)现有的大量Java Lib必须转换为Dalvik dex格式才行,但是遗憾的是,Dalvik并不完全支持所有的Java SE lib,针对ARM手机的设计和针对X86服务器的设计是需要适配大量OS层面的驱动,才能优化。

(4)但是Dalvik确实给JVM带来了不少的启示,比如可以在多个VM之间重用代码,采用类似DLL的方式,以及Jar采用基于内容的压缩等等。

?

相关信息:

http://en.wikipedia.org/wiki/Dalvik_%28software%29

http://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded

http://www.codemud.net/~thinker/GinGin_CGI.py/show_id_doc/385

  评论这张
 
阅读(662)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017