ARM硬件支持java技术Jazelle DBX
可以说,现在Java游戏已经发展成一项产业,三维图像、多人连线等更高级的支持也不鲜见。网络运营商和手机制造商希望出现更具可玩性的游戏,甚至跳出游戏应用发展诸如商务、定位、视频等各种各样的增值服务,以带来更多的收入。
为支持这些新的服务,J2ME平台必须快速发展,集成新的API(如移动3D),融入新的特性,比如能够运行多个MIDlet。移动设备上运行Java需要处理好这两个问题:Java分化和在资源有限的设备上如何保证Java的性能。
运营商和手机制造商为标准Java API加入了许多扩展,造成了一定程度上的“Java分化”,影响到了Java的进一步应用,产业链上各个环节的厂家不得不做额外投入以支持各种扩展。于 是Sun公司建立了JCP(Java Community Process)试图减少这种分化,同时努力能够跟上嵌入式设备上Java应用和变化的步伐。现在很多JSR扩展规范都是通过JCP提出的,证明JCP起 着正面的促进作用,能根本上解决分化问题。
嵌入式Java虚拟机的设计限制
目前市场上已经有大量宣称支持Java的手机,从技术上来看,许多中低端手机基本上是在30~50MHz ARM7TDMI处理器上运行一个小型的软件字节码(bytecode)解释器,相对较慢。这对许多的Java小游戏是够用了,因为其性能是由系统的图形处理能力决定的,对Java的要求不是特别高。但是市场发展变化很快,越来越多的Java应用需要更强的图形处理能力,以及一个强大的Java虚拟机。
![]() |
图1:指令流水线示意图。 |
几种加快Java执行速度的传统方法包括几种软件方案,如字节码解释器优化、即时(JIT, just-in-time)编译器、预先(AOT, ahead-of-time)编译器等;硬件方案有专用Java处理器和Java协处理器。这些方法在提高性能的同时,通常也会增加对功耗、内存的需求, 影响到了系统平台的成本,尤其是硬件方案。
JIT或AOT编译器是把字节码动态地编译成目标平台的本地码,然后直接执行。顾名思义,AOT编译方案就是在应用下载完后编译所有代码,而实际上 某些代码很有可能根本就执行不到。JIT编译方案则是运行到某段代码之前,只对这一段作即时的编译。这种即时处理策略会让用户在选择启动应用程序后,不得 不等待很长的一段时间程序才真正运行起来。另外,研究显示动态编译会导致代码膨胀4~6倍。因此,除了减慢应用程序启动速度,无论JIT还是 AOT方案,都需要很大的额外内存来保存编译生成的本地码。
动态编译技术
有一种弥补JIT编译器缺点的方法就是采用通常被称为动态自适应编译(DAC)的混合软件方案,它可以看成是JIT编译器和字节码解释器的组合。在 开始阶段,程序解释执行,同时软件对代码作分析并决定哪些关键代码需要被编译,这些关键代码被鉴别出来后,即被编译成本地码运行。
采用了DAC方案,JIT编译的一些负面影响可能会减少,但是JIT毕竟无法提供最好的速度性能,启动时间和代码膨胀的问题仍会比较突出。
在完成关键代码分析前,程序得运行于慢速的解释器模式,然后暂停再进行编译。应用程序启动时,许多函数方法仅运行一次,理想情况下不应该编译这些代码。从用户体验角度来看,影响是很明显的,尤其是程序启动阶段会感觉到较长时间内程序没有任何用户响应。
因为纯软件的解释器很慢,大多数DAC方案实际上很少做代码分析,而编译几乎所有的函数方法,就像赌博一样,赌这个函数方法接下去会执行很多次。如果赌错,将会付出更多的代价—不但花费了更多的编译时间,而且编译产生的那些不再运行的代码耗费了宝贵的内存资源。
编译的代码会占用内存资源,DAC必须从内存中删掉以前编译好的代码,为新的编译让出空间,接下去如果运行到刚被删掉的代码,又得重新编译。这样产 生了性能平滑度问题,因为在编译新代码或重编译过程中,程序得暂停执行。比如在切换游戏场景时,玩家会感觉到难以忍受的等待。
尽管动态编译存在一些缺点,可现在嵌入式设备的硬件配置也越来越高,尤其是RAM或ROM,因此诸如DAC甚至一些AOT方案变得很有吸引力。然 而,我们也看到一个系统平台中许多的组件是用Java开发的,越来越多的可下载应用是用Java写,多
ARM硬件支持java技术JazelleDB 相关文章:
- Windows CE 进程、线程和内存管理(11-09)
- RedHatLinux新手入门教程(5)(11-12)
- uClinux介绍(11-09)
- openwebmailV1.60安装教学(11-12)
- Linux嵌入式系统开发平台选型探讨(11-09)
- Windows CE 进程、线程和内存管理(二)(11-09)