在嵌入式设备上运行高性能Java

在嵌入式设备上运行高性能Java

作 者：
ARM中国

摘 要：
在过去几年里，无线手持设备
市场对Java产生了巨大的需求增
长，主要的增长力量来自于移动游
戏。广大消费者，网络运营商，服
务/内容提供商以及手机制造商强
烈渴望手机的Java性能更强劲，支
持更多更复杂的应用，为产业链各
方带来更多商机和收入。本文重点
关注嵌入式设备Java平台的需求，
尤其是Java虚拟机(JVM)。 目前存
在若干解决嵌入式设备Java性能问
题的方案，文章将分别提到这些不
同的方案，然后详细介绍ARM公
司的硬件Java加速技术—Jazelle®
DBX(Direct Bytecode eXecution)
。

应用广泛的移动Java

Java已经在各个领域得到了广泛的
应用，尤其是无线移动领域，全球超过
100个移动运营商已经推出了Java下载服
务。Java也正成为其它嵌入式设备的支持
标准，比如机顶盒。Java应用的快速增长
源于以下几点：
1 Java的设计初衷“一次编译，到处
运行”表明Java具备很好的可移
植性。开发和发布Java应用都很
便捷，快速上市，节省成本；
2 Java有着广泛的支持网络，众多的
第三方在开发各色各样的Java应用；
3 Java平台固有的安全性适合运营商
网络下载；
4 Java字节码代码密度较高，程序可
以较小以适合内存资源有限的嵌入
式设备。
可以说，现在Java游戏已经发展成
一项产业了，三维图像、多人连线等更
高级的支持也不鲜见。网络运营商和手
机制造商希望出现更具可玩性的游戏甚
至跳出游戏应用，发展诸如商务，定位，
视频等各种各样的增值服务，以带来更多
的收入。

嵌入式设备上的Java性能

目前市场上已经有大量宣称支持
Java的手机，从技术上来看，许多中
低端手机基本上是在30-50MHz ARM-
7TDMI处理器上运行一个小型的软件字节
码解释器，相对较慢。这对许多的Java小
游戏是够用了，因为其性能是由系统的图
形处理能力决定的，对Java的要求不是特
别高。但是市场发展变化很快，越来越多
的Java应用需要更强的图形处理能力，以
及一个强大的Java虚拟机。
说到手持设备上的Java性能，我们
不得不提一下Java性能评测。理论上，
任何Java程序都能在支持Java的设备上
运行，Java评测程序当然也不例外。许
多网站提供了各种各样的Java评测程序，
用户可以很方便的比较各款手机的Java性
能。比如著名的来自www.jbenchmark.
com 网站的JBenchmark，此评测指标已
经被各杂志媒体广泛引用。手机厂商当然
不甘示弱，努力使得自己产品的Java性能
指标位于前列。ARM公司也积极地通过
EEMBC协会(The Embedded Microprocessor
Benchmark Consortium)定义一项
业界Java评测标准。

嵌入式Java虚拟机的设计限制

几种加快Java执行速度的传统方法，
软件方案有JVM解释器优化，即时(JIT,
just-in-time)编译，预先(AOT, aheadof-
time)编译等；硬件方案有专用Java处
理器，Java协处理器。这些方法在提高性
能的同时，通常也会增加对功耗、内存的
需求，尤其是硬件方案，影响到了系统平
台的成本。
JIT或AOT编译是把字节码动态地编
译成目标平台的本地码，然后直接执行。
AOT编译方案，顾名思义，就是在应用下
载完后，编译所有代码，而实际上某些代
码很有可能根本就执行不到。JIT编译方
案则是运行到某段代码之前，只对这一段
作即时的编译。这种即时处理策略，会让
用户在选择启动应用程序后，不得不等待
很长的一段时间，程序才真正运行起来。
另外研究显示，动态编译会导致代码膨胀
4-6倍[1]。因此，除了减慢应用程序启动
速度，无论JIT或AOT方案，都额外需要
很大的内存来保存编译生成的本地码。

动态编译技术

有一种弥补JIT编译器缺点的方法就
是采用通常被称为动态自适应编译(DAC,
Dynamic Adaptive Compiler)的混合软件
方案， 它可以看成是JIT编译器和字节码
解释器的组合。在开始阶段，程序解释执
行，同时软件对代码作分析并决定哪些关
键代码需要被编译。这些关键代码被鉴别
出来后，即被编译成本地码运行。
采用了DAC方案，JIT编译的一些负
面影响可能会减少，但是JIT毕竟无法提
供最好的速度性能，启动时间和代码膨
胀的问题仍会比较突出。
在完成关键代码分析前，程序得运
行于慢速的解释器模式，然后暂停下来
编译。应用程序启动时，许多函数方法仅
运行一次，理想情况下不应该编译这些代
码。从用户体验角度来看，影响是很明显
的，尤其是程序启动阶段，会感觉到较长
时间内程序没有任何用户响应。
因为纯软件的解释器是很慢的，大
多数DAC方案实际上很少做代码分析，
而编译几乎所有的函数方法，就象赌博
一样，赌这个函数方法接下去会执行很
多次。如果没有赌对，那会付出更多的
代价—不但花费了更多的编译时间，而
且编译产生的那些不再运行的代码耗费
了宝贵的内存资源。
代码膨胀总会消耗完内存资源，
DAC必须从内存中删掉以前编译好的代
码，为新的编译让出空间，接下去如果运
行到刚被删掉的代码，又得重新编译。这
样产生了性能平滑度问题，因为在编译新
代码或重编译过程中，程序得暂停执行。
比如在切换游戏场景时，玩家会感觉到难
以忍受的等待。
尽管动态编译存在一些缺点，可现
在嵌入式设备的硬件配置也越来越高，
尤其是RAM或ROM，因此诸如DAC甚至
一些AOT方案变得很有吸引力。然而，
我们也看到一个系统平台中许多的组件
是用Java开发的，越来越多的可下载应
用是用Java写的，多Java程序并发执行
的需求也开始产生。这些发展趋势意味
着Java对内存的需求是无止境的。

硬件加速

硬件Java加速方案通常需要加入额外
的芯片，以及更多的功耗。专用Java处理
器支持直接执行Java字节码，看起来性能
不错，但是系统集成和开发的复杂度大幅
上升。Java处理器不会支持已有的很多操
作系统和应用程序，它得和其他的嵌入式
处理器配合使用。
Java 协处理器是把Java字节码翻译
成主处理器的指令。这当然需要许多软
硬件集成工作，要在操作系统加入对协
处理器的支持尤其困难。同样协处理器
需要额外的板上空间，额外的功耗，本
身也很贵。另外，协处理器和主内核之
间的松耦合连接方式决定了其运行速度
是相对较慢的。

硬件架构扩展和Jazelle DBX技术概要

在已有处理器架构上加硬件扩展可
以同样支持直接运行Java字节码，而且
保持了操作系统和应用程序的兼容性。架
构扩展方案相当于为处理器附加了一套指
令集，重用已有的处理器资源，不会增加
额外的硬件成本和功耗。带扩展的内核能
够同时执行Java字节码及本地码，开发者
可以充分利用已有的操作系统、应用程序
开发技术，在Java程序可移植性和性能之
间取得很好的平衡。
传统的ARM处理器都支持两套指令
集：32位ARM指令集和16位Thumb®指令
集。通常使用Thumb指令集的代码大小约
为ARM代码的35-40%，但会轻微降低程
序性能。指令集支持在ARM和Thumb代
码之间互相作函数调用，程序员可以在
编译时分别从性能和代码密度的角度考
虑以决定不同部分的代码编译成ARM或
是Thumb。
Jazelle DBX是一种硬件架构扩展
技术，为ARM处理器引入了第三套指令
集—Java字节码。新指令集建立了一种新
的状态，处理器在此状态下处理Java字节
码取指、译码，维护Java操作数栈。
为了减少芯片尺寸提高性能，Jazelle
DBX没有设计成传统形式的微引擎，而是
融入流水线中的一个有限状态机。和协处
理器或专用处理器设计不同的是Jazelle
DBX和主处理器共用缓存，这都会对功
耗和性能带来益处。
另一个重要的设计考虑是确保Jazelle
DBX技术不会影响实时性能，仍保
持与操作系统中已有ARM异常处理代码
的兼容。

Jazelle DBX技术细节

J a z e l l e D B X技术增加了一条新
的“Java跳转”指令来进入Java状态。
此指令支持条件执行，先检查条件标
志，如果条件满足，处理器进入Java状
态，跳转到指定目标地址，开始执行
Java字节码。
在Java状态下，PC寄存器仍是32位
寻址Java 代码。字节码取指、译码分别
在两个流水级完成（对应ARM/Thumb状
态下为一个译码流水级）。32位取指操作
一次性可以取4个Java字节码，性能优势
明显。
CPSR寄存器新定义了一个Java状态
指示位。这很重要，因为在处理中断或其
它异常时，CPSR会自动保存或恢复程序
运行状态。

Jazelle DBX技术允许所有的Java指
令是“可重新开始”的。这样在执行
Java指令过程中，即可响应中断，从而
减少中断延迟，确保实时性能。
在Java状态下，有若干个ARM寄存
器可以功能复用 (包括栈指针，栈顶四
项，局部变量0等)。正是这些硬件重用
设计，才使得只用了很少的附加逻辑(约
一万两千门)就实现了一个Java机。把所
有Jazelle DBX扩展所需的状态用ARM寄
存器保存，也保证了和现有操作系统，
异常处理代码的兼容性。
把栈顶四项保存在ARM寄存器中对
Java性能也很有益。大量的程序分析显
示大多数程序的栈深度是很小的，所以
这项策略可以尽量减少内存访问。硬件
也可自动处理栈溢出或下溢。
对于一个高度优化的商业J a v a虚
拟机( J V M )，运行评测程序或复杂的
MIDP2.0应用，Jazelle DBX技术通常可
带来约2-4倍的性能提升，而且对实时性
不会产生任何影响。
在嵌入式设备上，运行速度还不是
唯一的考虑因素。功耗，存储器占用，
集成的难度，系统成本，用户体验等都
很重要，需要很好的平衡。
Jazelle DBX技术把Java字节码分为
3类：直接执行的，模拟执行的和未定义
的。大多数Java字节码（ARM926EJSTM
支持134个）可由硬件直接执行；余下
的由一些简短的高度优化的ARM指令序列
来模拟。把原先虚拟机中的解释器拿掉，
替换以ARM专有的代码( 称为VMZ，这些
代码甚至比替掉的代码更小)。
统计分析表明在一段典型的程序
代码中，需要模拟执行的字节码不会超
过5%。这就是为什么ARM决定Jazelle
DBX硬件扩展只支持直接执行部分的字节
码，而非全部。要知道，Jazelle DBX硬
件设计约为一万两千门，而大多数的专
用Java处理器或协处理器通常有6万到
10万门的规模。这样的设计策略把硬件
逻辑的复杂度减到最小，功耗低，系统
集成难度低，却仍能表现出很高的整体
Java性能。
未定义的字节码与模拟执行的字节
码截然不同。一旦执行到未定义的字节
码，处理器退出Java态，进入ARM态执
行异常处理。有了这样的机制，就可以
以软件补丁的方式，实现对未来可能会
扩展的Java字节码支持。

为帮助用户使用J a z e l l e D B X，
ARM公司提供了JTEKTM软件包(Java
Technology Enabling Kit)，其中包含了
VMZ源代码，为一个现有的Java虚拟机和
操作系统集成JTEK通常只需几天时间。
ARM也和主流的Java平台供应商合作，
如Aplix/iasolution，Sun等，在他们的
软件产品中加入了Jazelle DBX支持。另
外，ARM和众多操作系统厂商合作，主流
的如WindowsCE, SymbianOS, PalmOS,
Linux以及许多实时专有的操作系统都也
支持Jazelle DBX。
TECHNOLOGY IN-DEPTH
Information Quarterly [20] Number 4, spring 2006
TECHNOLOGY IN-DEPTH
Information Quarterly [21] Number 4, Spring 2006

Jazelle DBX技术和动态编译

前面讨论中我们提到，动态编译技
术会带来一些固有问题，比如程序启动时
间长，代码膨胀，性能上不够流畅等。而
Jazelle DBX技术正好可以弥补动态编译
技术的这些不足。

使用Jazelle DBX技术，原先依靠纯
软件解释执行的程序，其启动延迟显著
减少。用户按下确认键启动程序，主界
面马上出现程序正式运行，这种性能表
现无疑会带来很好的用户体验。需要指
出的是Java评测程序很少把程序启动时
间这项作为评测项之一；ARM公司开发
了ARMFLO评测软件，专门评价程序的

启动时间和运行过程中的平滑度。

表1显示了ARMFLO和其它两个有
代表性的Java应用Oplayo[2]和Navitime[
3]，分别运行于Sun CLDC-HI，集
成了JTEK-M的CLDC-HI，以及集成了
JTEK-K的CLDC/KVM上的启动时间。
评测结果清楚显示了Jazelle DBX技
术显著减少程序启动时间，甚至使得
CLDC-HI动态编译方案和KVM解释执行

方案两者的启动时间很接近了。

在DAC方案中加入Jazelle DBX支
持意味着编译可以少一些而解释则多一
些，这样节省内存且不影响性能。Jazelle
DBX技术也可以减少编译进一步提
高DAC方案的性能：
 那些无需或很少重复运行的代码，不
必参与编译，节省编译消耗的时间；
 部分代码解释执行，意味着有充分
的时间用以编译出高质量的本地代
码，运行更快；
 更有效地利用内存，也是更好地利
用缓存和存储带宽，这点对16位数
据总线尤显重要。

对于解释器方案，如K V M或基于
KVM的Java虚拟机，Jazelle DBX的加速
表现特别明显，这样一个VM就能以良好
的性能表现运行在许多不同类型的嵌入
式设备上。
有了Jazelle DBX支持，DAC编译器方
案可以少做一些编译，对ROM, RAM等硬
件资源的要求相对低了很多(通常ROM需
求减少约33%)，一个Java VM同样可以
运行于更多的嵌入式设备上。

结论

移动Java游戏促进了Java在无线设
备上的应用，Java固有的端对端的安全
性和Java应用开发的快捷性使Java成为
新的收入增长点。在资源有限的嵌入式设
备上也需要高性能的Java平台，Jazelle
DBX这样的加速技术正是应对了这样的
需求，其他一些硬件或纯软件加速方案
将极大地受益于Jazelle DBX，并避免原
有的各种缺点。
通过各种新特性的加入，A RM处
理器架构持续创新。ARM公司将在未来
架构发展中，继续支持Jazelle DBX以
及后续的新技术。目前采用了Jazelle
DBX技术的手机已经被证明几乎是市场
上Java性能最好的，提供了极佳的用户
体验。Jazlle技术和相应的JTEK软件包
将更广泛的促进Java在嵌入式设备
上的应用，更多更新的移动Java应
用随之涌现。

参考
[1] Code Cache Management in Dynamic
Optimization Systems. Kim Hazelwood
Cettei.
http://www.eecs.harvard.edu/~cettei/
docs/phdthesis.pdf
[2] http://www.oplayo.com/
[3] http://www.navitime.co.jp