分类： LINUX
2008-11-18 10:26:58
已经在各个领域得到了广泛的应用，尤其是无线移动领域，全球超过100个移动运营商已经推出了Java下载服务。Java也正成为其它嵌入式设备的支持标准，如机顶盒。Java应用的快速增长源于以下几点：尽管Java的可移植性一直有争论，但无庸置疑的是其快速上市的优势，开发和发布Java应用都很便捷；Java有着广泛的支持网络，众多的第三方在开发各色各样的Java应用；Java平台固有的安全性适合网络下载。
可以说，现在Java游戏已经发展成一项产业，三维图像、多人连线等更高级的支持也不鲜见。网络运营商和手机制造商希望出现更具可玩性的游戏，甚至跳出游戏应用发展诸如商务、定位、视频等各种各样的增值服务，以带来更多的收入。
为支持这些新的服务，J2ME平台必须快速发展，集成新的API(如移动3D)，融入新的特性，比如能够运行多个。移动设备上运行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写，多个Java程序并行执行的需求也开始产生。这些发展趋势意味着Java对内存的需求是无止境的。
硬件加速
硬件Java加速方案通常需要增加额外的芯片以及更多的功耗。专用Java处理器支持直接执行Java字节码，这虽然看起来性能不错，但是系统集成和开发的复杂度却大幅上升。Java处理器不会支持已有的很多操作系统和应用程序，它需要和其他的嵌入式处理器配合使用。
|
图2：采用ARM处理器的Java应用架构。 |
Java协处理器是把Java字节码翻译成主处理器的指令。这当然需要许多软硬件集成工作，要在操作系统加入对协处理器的支持尤其困难。同样协处理器需要额外的板上空间和额外的功耗，而且本身也很贵。另外，协处理器和主内核之间的松耦合连接方式决定了其运行速度相对较慢。
硬件架构扩展和技术
在已有处理器架构上加硬件扩展可以同样支持直接运行Java字节码，而且保持了操作系统和应用程序的兼容性。架构扩展方案相当于为处理器附加了一套指令集，重用已有的处理器资源不会增加额外的硬件成本和功耗。带扩展的内核能够同时执行Java字节码及本地码，开发者可以充分利用已有的操作系统、应用程序开发技术，在Java程序可移植性和性能之间取得很好的平衡。
传统的ARM处理器都支持两套指令集：32位ARM指令集和16位Thumb指令集。通常使用Thumb指令集的代码大小约为ARM代码的35~40%，但会轻微降低程序性能。指令集支持在ARM和Thumb代码之间互相作函数调用，程序员可以在编译时分别从性能和代码密度的角度考虑，以决定不同部分的代码编译成ARM或是Thumb(图1)。
Jazelle DBX是一种硬件架构扩展技术，为ARM处理器引入了第三套指令集—Java字节码。新指令集建立了一种新的状态，处理器在此状态下处理Java字节码取指、译码和维护Java操作数栈。
为了降低芯片尺寸并提高性能，Jazelle DBX没有设计成传统形式的微引擎，而是融入流水线中的一个有限状态机。和协处理器或专用处理器设计不同的是，Jazelle DBX和主处理器共用缓存，这都会对功耗和性能带来益处。另一个重要的设计考虑是确保Jazelle DBX技术不会影响实时中断性能，仍保持与操作系统中已有ARM异常处理代码的兼容。
Jazelle DBX技术增加了一条新的“Branch-to-Java”指令来进入Java状态。此指令支持条件执行，先检查条件标志，如果条件满足，处理器进入Java状态，跳转到指定目标地址，开始执行Java字节码。
在Java状态下，PC寄存器仍是32位寻址Java字节代码。字节码取指、译码分别在两个流水级完成(对应ARM/Thumb状态下为一个译码流水级)。32位取指操作一次性可以取4个Java字节码，性能优势明显。
当前处理器状态寄存器(CPSR)新定义了一个位，用来记录处理器的状态。这很重要，因为在处理中断或其它异常时，CPSR会自动保存或恢复程序运行状态。
Jazelle DBX技术允许所有的Java指令是“可重新开始”的。这样在执行Java指令过程中，即刻响应中断，从而减少中断延迟，确保实时性能。
在Java状态下，有若干个ARM寄存器可以功能复用(包括栈指针、栈顶四项(top4 elements of stack)、局部变量0等)。正是这些硬件复用设计，才使得只用了很少的额外逻辑(约一万两千门)就实现了一个Java机。把所有Jazelle DBX扩展所需的状态用ARM寄存器保存，也保证了和现有操作系统、中断处理程序和异常处理代码的兼容性。
把栈顶四项保存在ARM寄存器中也能提高Java性能。大量的程序分析显示，大多数程序的栈深度是很小的，所以这项策略可以尽量减少内存访问，硬件也可自动处理栈溢出或下溢。
Jazelle DBX技术的性能
对于一个高度优化的商业Java虚拟机，运行评测程序或复杂的MIDP2.0应用，Jazelle DBX技术通常可带来约2~4倍的性能提升，而且对实时性不会产生任何影响。
对于嵌入式设备来说，运行速度还不是唯一的考虑因素，功耗、存储器占用、集成的难度、系统成本和用户体验等都很重要，需要很好的平衡。
Jazelle DBX技术把Java字节码分为3类：直接执行、模拟执行(emulated)和未定义。大多数Java字节码(ARM926EJ-S支持134个)可由硬件直接执行，余下的由一些简短的高度优化的ARM指令序列模拟执行。把原先虚拟机中的解释器去掉，替换以ARM专有的代码(称为VMZ，这些代码甚至比替掉的代码更小)。
统计分析表明，在一段典型的程序代码中，需要模拟执行的字节码不会超过5%。这就是为什么ARM决定Jazelle DBX硬件扩展只支持直接执行部分的字节码，而非全部。Jazelle DBX硬件扩展的实现约为一万两千门的规模，而大多数的专用Java处理器或协处理器通常有6万到10万门的规模。这样的设计策略把硬件逻辑的复杂度减到最小、功耗低、系统集成难度低，却仍能表现出很高的整体Java性能。
未定义的字节码与模拟执行的字节码截然不同。一旦执行到未定义的字节码，处理器退出Java状态，进入ARM状态执行异常处理。有了这样的机制，就可以以软件补丁的方式实现对未来可能会扩展的Java字节码支持。
为帮助用户使用Jazelle DBX，ARM公司提供了JTEK件包，其中包含了VMZ源代码，为一个现有的Java虚拟机和操作系统集成JTEK通常只需几天时间。ARM也和主流的 Java平台供应商合作，如Aplix/iasolution和Sun等，在他们的软件产品中加入了Jazelle DBX支持。另外，ARM和众多操作系统厂商合作，主流的如WindowsCE、SymbianOS、PalmOS、Linux，以及许多实时专有的操作系统都支持Jazelle DBX。
本文小结
移动Java游戏促进了Java在无线设备上的应用，Java固有的端对端的安全性和Java应用开发的快捷性使Java成为新的收入增长点。在资源有限的嵌入式设备上也需要高性能的Java平台，Jazelle DBX这样的加速技术正是应对了这样的需求，其他一些硬件或纯软件加速方案将受益于Jazelle DBX，并避免原有的各种缺点。
通过融合各种新特性的加入，ARM将在未来架构发展中继续支持Jazelle DBX以及后续的新技术。Jazlle技术和相应的JTEK软件包将更广泛的促进Java在嵌入式设备上的应用，更多更新的移动Java应用将随之涌现。
