Inside KVM-探矽工作室

谈到Java，大家都说这是最有「钱景」的语言，不过再谈下去，大家恐怕就会安静下来，因为执行的速度实在太慢了，慢到即使现在的CPU都已经上GHz等级的时代，大家还是有志一同的说：这个语言还有改善的空间。 我们翻开Java的历史来看看，在1991年Sun Microsystems Inc. 的绿色计画（Green Project）打算发展消费性电子产品，原本使用C、C++语言当作计画的主轴，但後来发现这些语言的功能，无法达到他们的理想目标，加上网路兴起的因素，随之就与有志之士着手设计一套完全物件导向，且不受平台限制的语言，原本以公司外面那一棵橡树之名称这套语言为oak，然这个名字又已经有人使用，於是设计小组最後突发奇想，以开会时的咖啡厅之名命之，此即为Hot Java的由来，所以我们看到其图样有杯热滚滚的咖啡！  Java为什麽称为最有前景的语言呢？原来他具备了所有程式设计师的梦想特色，「跨平台的语言」、「极佳的安全性」、「适合网路应用」、「容易撰写应用程式」，甚至升阳公司的执行长Scott McNealy还做出一个结论：『Write once, run anywhere on anything safely』。 图、Java系统结构图 不过为了达到这些目的，Java采用了两个部分组成整体架构，即虚拟机器（Virtual Machine）和应用程式介面（API），我们可以把虚拟机器看成是一套虚拟的电脑，就是说用软体来模拟一个电脑，但是因为这个Java虚拟机器是以堆叠机器(Stack Machine)的概念作成，这也就是说，以1+2=3为例，Java虚拟机器会先把运算元，也就是1与2放入堆叠中，在一一由堆叠顶端拿出来做运算，运算结果(也就是3)再放进堆叠中。原本普通只要一个CPU指令就可以做完的动作，却因为还要作堆叠的动作，花了四、五个指令才能做完，造成效率不彰。 前面笔者不是提到绿色计画不就是为了发展消费性电子产品而诞生的吗？那Java如此的现况，还是合适发展消费性电子产品吗？答案当然是肯定的，最近这一两年来，由於行动终端装置的蓬勃发展，不仅使用的人口日益扩增，连带使得加入发展的软硬体厂商也汹涌而至。各式各样的硬体设备，软体平台都被开发出来以加入这一场21世纪的行动通讯大战。在硬体装置上有Intel公司的StrongARM系列，Motorola公司的Dragon ball系列等等；软体平台则有着名的Linux作业系统，Microsoft的Pocket PC，Accelerated Technology公司出品的Nucleus PLUS等等。因此在一个拥有这麽排列组合的环境下，一个程式设计师如果想要撰写出能够横跨这麽多平台的应用程式出来，那将是一件不容易的事情。所以我们不禁要佩服升阳公司能够早在十年前就可以预料到现在的状况，而发展Java语言。 因此针对消费性电子产品与其他桌上型电脑之间的不同，升阳公司不再要求Java必须统一，而是针对不同平台特性，发展不同的版本，这也就是目前大家耳熟能详的Java2的由来。在Java2里面，针对小型的消费性电子产品，特别制订了一个版本，称为J2ME(Java 2 Platform Micro Edition)，这是为了市场日渐壮大的资讯家电设备在2000年所发展出来的微型Java技术，主要的应用可以分为两大类，个人行动装置和共用固接装置。其中专为J2ME所发展的虚拟机器就是KVM(K Virtual Machine)，这是为了在有限系统资源下执行Java 应用的虚拟机器，对记忆体的需求量在Kilo Bytes等级里故命此名之。图、Java应用运作流程 为了突破效率上的障碍，深入研究这种专为嵌入式产品所打造的KVM实作恐怕是必须的，传统的Java程式采用了一些特别的方法来解决效率的问题，Just in time Compiler（JIT compiler）针对Bytecode需执行时才去翻译，如上图所示，但是在KVM中，必须要更简化这些流程，例如KVM把byte code verify的动作分成两步，先用预先审核器(preverifier)做一些前置的审核工作，预先审核器会在类别档之中加入一些特殊标记或符号。如此一来，当这些程式放到目标平台上执行时，就可以大幅减少在目标平台上做审核时的时间，藉而加速程式的的启动及执行速度。所以KVM的应用程式发展流程就会像下面这张图的流程一样，比起一般的Java程式开发来说，多了许多的步骤。 图、Java 程式发展及载入具有KVM 的目标平台的流程 另外一招，既然效率问题卡在KVM本身，所以我们可以选择就针对KVM作许多最佳化的动作，升阳公司的KVM参考实作是采用C语言，我们可以仔细分析这个参考实作，把一些瓶颈部分改采用组合语言来撰写，或是开启一些效能选项，让KVM本身的效率变快，不过根据笔者初步的实际测试，这招可以让整个KVM效能上升约10% - 20%。 如果KVM也调整了，效率还是不佳呢？还有一招，就是把Java method改成用native code实作出来，这个方案的中心想法是：native code并不需要经过interpreter的解释而是直接送给作业系统执行，所以它避开了效能瓶颈的Java虚拟机器，因此可以提升整体的执行效率。不过这招的问题是目前的J2ME中并没有包含JIT的功能，因为如果要再系统资源缺乏的小型装置上实作出这种机制出来的话，将会大幅的降低J2ME的可用性。 <<到底什麽是native code？>>读者可以把它想像成使用传统C语言所撰写而成的程式码。因为使用C语言所撰写而成的程式码可以被编译成底层硬体看的懂得机械码，就好像是机器的母语一样，所以我们把它叫做native code。相对来说，由於使用Java语言所撰写而成的程式码只能在Java虚拟机器上执行，不能直接被底层的作业系统与硬体所执行，因此会造成效率上的落差。其实，任何一种程式语言，只要使用该程式语言所撰写而成的程式码，可以被该种语言的编译器编译成底层硬体所能看的懂得机械码的话，使用该种程式语言所撰写而成的程式码都可被称为是native code。不过一般说来native code都是指传统的C或C++程式语言。 最後一招就是Java Byte Code Interpreter ，使负担最重的的部分由硬体去解决，就是我们常听到的Java Chip，如JavaSoft 与Sun Microelectronic 的PicoJava，MicroJava 和 UltraJava晶片以及ARM公司的Jazelle的技术，这招就是最後绝招了，而且实际的效率也真的让人满意。由於手机市场上面，目前ARM占了绝大多数的市场，因此一旦ARM所推出具有Java硬体加速的CPU广为手机制造厂商所使用，将来可以预期的就是具备Java功能的手机将会更为普及。 图、Jazelle系列晶片上的软体架构。（资料来源：http://www.arm.com ） 经过这一大串的解释之後，可能读者开始抗议，为什麽讲这些东西呢？其实笔者只是想指出一个已经存在的现象，在目前的Java手机中，都已经号称可以执行一些Java的程式了，不过经过上面的解释之後，读者再来想一想我们拿到用来在Java手机上所执行的程式，会不会赫然发现只有一些简单的游戏程式？比较复杂的程式几乎可以说不存在。讲到这边一定有读者开始抗议，中华电信不就配合Motorola太极二代的Java功能，推出一款类似股票机功能的服务吗？没错，这大概是笔者目前发现比较实用而且复杂的程式，不过如果读者想要把这支股票服务的Java程式拿到其他厂牌的Java手机，例如说是西门子的Java手机上面，是否可以执行？很不幸的，笔者必须诚实的说：「不行」！不然为什麽中华电信到目前为止还只能够在太极二代上面使用这项服务，而无法广为让各种手机一起使用呢？ 那读者一定要开始抗议，Java程式不就是号称可以跨平台吗？怎麽变成这样呢？其实道理在前面都描述过了，就是因为复杂的程式或多或少都会用到一些该手机或是平台才有的一些特殊功能，这些并没有定义在标准的Java规范当中，但是却是合法可以使用的部分，就算通通都没有用到好了，光是显示萤幕的大小就够程式设计人员头痛不已了。 举另外一个例子来说，在J2ME的范围里面，PDA和手机是摆在一起的，现在在Palm或是iPAQ上面已经有不少的Java程式，而且许多程式本身也相当具有份量，但是直接放在Java手机上面执行看看，先花了大把的功夫把Java程式放到手机里面，就需要花费许多时间来研究，不信你看看现在那一本J2ME实作的书籍或是文章有告诉你这个步骤怎麽作？全部都是使用Sun公司所提供的模拟器当程式范例与模拟而已，可是连放上手机执行都不那麽的直观，提供下载的地方也寥寥可数，这个技术的应用程度还是有待考验。 经过千辛万苦，搞了半天，终於塞到手机里面去，结果竟然不能够执行，最後还是只有一些简单的游戏可以跑，这个痛苦的经历真可呼应升阳公司的执行长Scott McNealy的名言来个对句：「Write once，debug everywhere」，也因为目前的技术如此的不切实际，因此这对於想要积极投入这方面的人来说，可能还是先等一等比较好。 至於手机厂商有没有看到这些问题，当然有罗！许多研究单位正积极研究到底如何才能够兼具效率与操作的方便度？为了拉近Java程式与真实手机之间的搭配，许多的规格也纷纷出笼，手机厂商之间的各种联盟与合作计画也正如火如荼的展开当中，相信在过不久，这些问题都会获得适当的解决。 用Java程式语言所撰写出来的应用程式之所以能够跨平台执行，在背後其实有着数十种不同的机制在运作。不论是独特的内部组译回圈，特殊的Java class档案结构，最初的启动载入的机制等等，这些看起来与传统程式语言差异很多的部分，其实不仅构成了Java软体环境的核心，而且在实际去了解它们的运作机制之後，更能加深读者们在运用Java程式语言撰写应用程式的能力。有一句话是这样说的：没有看过Java虚拟机器的内部，不能说是完全的了解了Java程式语言。在这个量身定作的KVM里面，更值得大家一探嵌入式Java虚拟机器！ 参考资料： 深入嵌入式爪哇虚拟机器 – Inside KVM, 探矽工作室