|
Java 扮演嵌入式应用开发主角
0 o9 ]+ k5 C; } p2 c
8 o: M, s! U$ n! w来自:计算机世界 建苗
" p8 u/ B# y: t
7 ^8 N7 U7 B* B5 o# X( p; `' J \2 U/ {, Y; G- }
嵌入式 Java 会在下一代移动电话、智能卡、无线设备、游戏装置及其他许多嵌入式应用中扮演重要角色,关键在于选择哪一种实现方法。
6 J! X2 O3 Q9 ]/ Z `% y) E8 p) p6 v- S3 K$ B
Java 自从推出以来一直备受关注,不过在嵌入式系统设计师看来,其性能并不能令人满意。运行 Java 虚拟机( JVM )解释 Java 字节码这种方式对大多数嵌入式应用来说占用空间过多,运行速度过慢。不过 Sun 的 Java 2 Micro Edition ( J2ME )改变了这种状况。
. }" V( K) C& [- H C9 |+ ^: K k0 q$ k& c J) ?( W# @( z
对嵌入式系统设计师来说, Java 有许多优点。作为一门编程语言, Java 允许面向对象编程,又没有 C++ 中存在的严重问题。例如, Java 允许类继承,但不允许来自多个父类,这就排除了产生混淆的可能;同样, Java 防止了 C++ 定义运算符时允许出现的不确定性。 Java 运行时环境还提供了有用属性,它通过先检查 JVM 中的代码然后再执行来确保应用程序不会相互干扰,以及整个系统不会崩溃,如果代码试图改变系统的核心行为,它就无法运行。 Java 提供的内存管理功能使得编程人员不必分配及释放内存,避免了内存泄露的可能,它还能通过垃圾收集方法,自动释放闲置内存。运行时环境甚至可以通过整合核心类库来简化程序分配。( C3 M. F" D6 t, B& ]4 o1 b& h% O0 |* F
% ~/ x. k0 b9 _ 此外, Java 在业界得到了广泛支持,这意味着有众多资源可以利用,包括小应用程序和经验丰富的编程人员,从而每次编写新应用程序无需重复性工作。; h0 x3 Y& X$ @6 z5 ]
3 q! I6 B3 t& ~. {" p7 j7 g 但在上述这些优点之外, Java 用于嵌入式开发的问题在于,大多数嵌入式应用面临 Java 没有处理好的两大约束:没有足够的空间和时间。
. T0 C% q+ k" d3 l- g2 M7 W5 E- G+ O/ ~$ P1 f7 F
Java 开发的时间和空间约束
) F! }$ y; g5 x( d' d2 I$ i
& ]3 W# ^# U4 o% W+ C) P+ v 之所以会有时间上的约束,是嵌入式系统通常必须在短时间内对外部事件做出响应,如果系统在下一个事件出现前没有处理好前一个事件,就无法完成任务。
$ S ~' s3 {) F* L$ n7 E3 Y/ n4 R) y* y6 w: n) h
时间上的约束还意味着需要确定性。设计师依靠软件元素,在已知或者有限的时间内完成各自的任务,本身没有时间限制的任务(如等待循环)在执行时间攸关的任务时,能够暂停挂起。
) y; `, B- n9 N+ E6 u4 s
" w% I2 Z1 ]# [# V3 }3 K 嵌入式开发的空间约束来自对成本和便携性的需求。设计师需要尽量少用内存,往往使得设计受微控制器的片上内存资源的制约。但这也有助于降低功耗,这是电池供电的便携系统所考虑的一个重要因素。$ j# w- K- |5 R( B2 `
) {# y3 k, @+ J. Y 在这些时间和空间的约束下 Java 很难正常工作。 Java 软件环境要与操作系统协同工作,并使用 Java 虚拟机把 Java 字节码转换成系统处理器的本机语言。它还需要相当大的类库,作为核心系统的一部分。这两种因素大大增加了对系统内存的需求。1 S3 r$ [8 }2 q1 } `7 X' t0 ?
' m$ P# |+ n! [ Java 的解释码运行起来本身就不如编译码快,这样一来,系统更难满足实时约束条件了。速度更快的处理器或许能帮上忙,但功耗因素往往使得嵌入式系统无法使用更快的处理器。就算系统足够快, Java 的垃圾收集算法也没有时间限制、不可中断,就不可能获得确定性。
+ D1 i9 S& L( u# @% h. N5 s9 ?& `9 D+ K# `' L
J2ME 定义两类 Java: M) y8 t* h3 S* a% j6 M! ^/ M# j5 ?
/ T4 N5 y$ Y# I/ N 对于 Java 在嵌入式开发中遇到的问题, J2ME 可以解决其中的一部分。办法是缩减类库大小,并且改变垃圾收集算法。 J2ME 定义了两类 Java :连接设备配置( CDC )和连接有限设备配置( CLDC ),让 Java 得以适用于诸多嵌入式系统,如下表所示。这些 Java 取代了较旧的嵌入式 Java ,而旧版本实际上是用于定制应用的非标准版本的 Java 。
; g5 b; D7 c1 S: K- D# c
! |! l2 n7 ^8 l& ~; i% \8 V CDC 是一种功能齐全的 Java ,面向配有网络连接、 32 位处理器和供 Java 平台使用的 2MB 内存的设备。这个版本的 Java 允许设备以类似桌面机的方式,下载及运行通用的小应用程序。 PDA 、家用电器和汽车导航系统就是适合的目标应用。
! i1 x& `0 X# W) T+ a
2 `% ^# `, t6 {. S" @2 t) S CLDC 是一种精简版的 Java ,面向运行时环境更加定制的应用。 CLDC 并不允许运行通用小应用程序,而是要求 Java 程序符合设备的约束条件。这样一来, Java“ 编写一次、到处运行 ” 的优势也就无从谈起,不过它仍保留了 Java 编程的其他优点。 CLDC 及其 K 虚拟机需要 160KB 的内存和 16MHz 的 16 位处理器。+ J A, k' L' F) ^% H* B, X; w( h2 O
. Z; k( t5 `1 C; c. z
Sun 利用这两种配置,开发出了符合许多嵌入式系统设计空间约束的标准 Java 配置, Java 社区制订的实时 Java 规范使得实时和确定性问题迎刃而解。实时 Java 规范( RTSJ ) V1.0 提供了 Java 平台的标准扩展部分,并且改动了垃圾收集算法,确保了 Java 提供许多嵌入式应用所需的确定性。
# g+ n, \0 C0 u9 j) @% D0 }- b$ j" S5 X5 ~0 p- e, l0 Y# h' i
这就只剩下原始性能问题还没有加以解决。解决办法来自行业提高 Java 执行速度的一系列方法,包括使用优化的 JVM 、执行前先把 Java 代码编译成本机码,使用及时( JIT )编程器以及使用硬件加速,每种方法各有优缺点。
+ @2 {# l2 x+ P4 C1 ^: {3 F; I+ b6 ^) k6 S/ M* [8 E% w: D
与普通 JVM 相比,优化的 JVM 通常可以把执行速度提高 2 ∼ 2.5 倍。不过,这种优化要针对特定处理器。提供优化的 JVM 的厂商可能还会提供优化的类库和实时操作系统,能够与 JVM 密切合作,进一步提高软件性能。. {1 U3 ~4 f, V5 S; `4 e+ s
! o+ B; p- A7 E/ T r
不管有没有经过优化,使用 JVM 仍需要解释工作,这就限制了程序的执行速度。把 Java 代码编译成本机码、然后再执行可以避免这种限制。这种情况下, Java 成了类似 C++ 的另一种高级语言,限制执行速度的因素完全取决于编译器的代码效率。问题在于,与其他高级语言一样,必须在把代码植入程序内存之前,先进行这种编译,结果导致系统缺乏灵活性,无法下载升级的 Java 代码或者是新的应用程序。* J. x1 Y- {6 p7 m* `/ A2 _
6 z4 X2 V9 c4 U! m 及时编译器力求通过 “ 高速 ” 编译 Java 代码以便可以立即执行,重新获得这种灵活性。这带来了高性能和灵活性,但也增加了特定应用程序的启动时间,因为需要先开始编译。由于至少占用 100KB 的内存(加上 JVM 和应用程序所需内存),使用及时编译器还加大了对系统内存的需求。
( `$ y& |; |. b4 ~
' I9 c* V% M% i% f# T, w) i( F) s% G 硬件加速 Java7 y- L+ @9 [( Y5 N( l9 a+ p
$ C4 M Z* R# \) X6 A" X 为了加快 Java 执行,又避开编译或者软件 JVM 的缺点,嵌入式开发人员可以求助于硬件加速器。这种设备把 JVM 的部分或者全部任务转交给专用硬件去处理,因而性能比解释的 Java 提高了 5 ∼ 10 倍。不过,硬件加速器并不接管所有任务,主机 CPU 仍处理特别复杂或者很少使用的字节码。
- ~; W; Z0 c+ k
- W. c5 M7 j1 T 半导体厂商采用了几种方法,通过硬件来加快 Java 的执行速度,致力于不同任务。 s" i2 f' i9 l% p) O# b! \4 Q2 H
& o- Y q& @0 A2 v9 z
一种是使用硬件解释器。该解释器把进来的 Java 代码的大部分转化成本机码,从而给 JVM 省去了麻烦。例如 Nazomi 的 Jstar 、 InSilicon 的 JVX 和 ARM 的 Jazelle 。大多数情况下,解释器拥有硅知识产权,这实际上扩大了处理器的指令集。
: x9 p5 t9 n% }' `% \! \3 Q# K* Y
" I# p0 Y! C& |- j& } 另一种方法就是使用协处理器。协处理器不仅解释字节码,还执行由此生成的机器码,让 CPU 完全得到解放。协处理器实际上是一种处理器,使用 Java 字节码作为本机机器语言。有些协处理器如 InSilicon 公司的 JVXtreme 是纯粹的协处理器,而有些协处理器如 Aurora VLSI 公司的 Espresso 和 DeCaf 可以充当协处理器或者独立处理器,这样在另一个 CPU 处理用户界面等事务时,可以处理 Java 代码。 Ajile 公司的 aJ-100 、 DCT 公司的 Lightfoot 和 Zucotto 公司的 Xpresso 都是协处理器。与解释器一样,这些协处理器往往作为用于 ASIC 或者 FPGA 实现的核心。
1 e/ m- I- m; j+ G
9 W4 r! D9 p6 q9 A. U 第三种方式是利用硬件及时编译器高速编译 Java 字节码。这种设备有别于硬件解释器,它不仅仅把软件从一种形式转换成另一种形式,实际上还能够编译,包括进行优化、重新安排代码执行次序等。 Parthus 公司的 MachStream 就属于这一类。1 j' o* o1 Q" a+ l: M
( D7 l+ R; y M 有了这一系列加快 Java 代码执行速度的软硬件方案,嵌入式系统的 Java 性能问题似乎可以得到解决了。遗憾的是,很难预测它们会给性能带来多大幅度的提升。加速器与其他系统单元的相互关系更是加大了预测难度。 CPU 架构、可用系统内存的数量、实时操作系统( RTOS )、 JVM 、类库和硬件加速都可能影响系统的最终性能,甚至应用软件也会对性能产生影响。例如适用于 Internet 设备的系统软硬件配置在机顶盒里面运行起来可能会比较慢,在移动电话上就完全不适合。; Z2 W1 W% g: B( f: L
) {% o' ]9 Q. ~5 S% H( Z. Y) I" Z6 n' U 遗憾的是,嵌入式设计师没有多少工具可以帮助自己测试非传统配置的性能。最有用的工具就是系统性能测试公司开发的 SPEC JVM98 基准测试。但 SPEC JVM98 不是为了满足嵌入式系统的测试需求,而是为联网和独立的客户机开发的,并且前提是假设完全实现了 Java ,并拥有完整的桌面系统环境,而很少有嵌入式系统拥有这么丰富的资源。
2 \1 I0 g) q& p) b/ V7 A( n# Z" K( b- ]
Pendragon 软件公司的 CaffeineMark 这个基准测试在嵌入式领域颇为流行。与 Dhrystone MIPS 基准测试一样 ,CaffeineMark 也是一种人工基准测试,仅仅测试几项 Java 特性,不包括浮点运算、垃圾收集和多线程这些项目,而对这些嵌入式开发人员来说可能很重要。另外,没有标准配置可供基准测试来运行。因而,不同厂商的基准测试结果很难解读。! Y: N: p# G6 E0 r4 E+ I
) y6 w% S1 `! W3 F 对嵌入式 Java 而言,缺少测试工具问题也许不会长期存在。 EDN 嵌入式微处理器基准测试协会 (EEMBC )已开始开发 Java 基准测试套件。 EEMBC 基准测试准备采用诸多系统测试指标,包括垃圾收集时间和确定性、 I/O 性能、中断时延、内存使用以及测试过程中的系统功耗。还会包括详细的软件执行基准测试,测试项目包括类加载时间、类方法执行、所用线程数量、每个线程所用时间、以及调用线程的时间。该协会计划在众多应用环境下进行基准测试,包括智能卡、移动电话、掌上设备、 Internet 设备和机顶盒。& t/ _# u5 q: ~8 s& S% U+ D9 O. O
一旦这些工具准备到位,就可以根据预期应用来进行比较,从而大大方便了开发人员选择嵌入式 Java 的诸多方案、确保系统的最终性能能够达到预期。那样, Java 可以在将来的嵌入式系统开发当中扮演主角。 |
|