ARM硬件支持java技术Jazelle DBX

Java已 经在各个领域得到了广泛的应用，尤其是无线移动领域，全球超过100个移动运营商已经推出了Java下载服务。Java也正成为其它嵌入式设备的支持标 准，如机顶盒。Java应用的快速增长源于以下几点：尽管Java的可移植性一直有争论，但无庸置疑的是其快速上市的优势，开发和发布Java应用都很便 捷；Java有着广泛的支持网络，众多的第三方在开发各色各样的Java应用；Java平台固有的安全性适合网络下载。

可以说，现在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写，多