浅谈 Java VM 发展

浅谈 Java VM 发展
Jim Huang <jimchyun @ ccns.ncku.edu.tw>
<jserv @ kaffe.org>

略为整理笔者对 Java VM 实作的心得，与诸位分享，在本文后半部将专注于若干
Open Source Java VM 项目的探讨，笔者本身是 KaffeVM [1] 开发者，很希望本文
能对看倌有所帮助，更期待您的来信指教，藉由技术交流，让 KaffeVM 有更好的发
展。
[1] http://www.kaffe.org/

■ JVM (Java Virtual Machine) 与 Java 韧体

Java VM 为一个虚拟的平台，把这个平台加以硬件实作，即 materialized 后，就是
Java chip。简单来说，它就是一颗货真价实的 CPU，假若我们不需完整 CPU 复杂的
设计，一样可以将它弄成 co-processor，如此一来，就不须要在 x86 或 Sun Sparc
上用 Java VM 来模拟，而是直接把 Java bytecode「喂给」Java chip 上执行。这
就是早先 Sun 称为 picoJava 的技术，当然，随着各软硬件厂商的投入，引入更复
杂的技术，但原则上观念还是一致的。

「模拟」既然非真，当然在效率上就较吃亏了，所以就常给人 Java 执行超慢、超耗
资源的印象，其实那是指 Virtual Machine 的效能。为了改进 JVM 效能，使用许多
技术加速，其中最重要的莫如 JIT (Just In Time) Compiler (及时编译器，注意：
不要跟「实时」[realtime] 搞混) 与 HotSpot 的 Adaptive Compiler 等 dynamic
compilation 技术。

Java Chip 是 Optimized for Java 的 OOP、exption-handling、memory/garbage
collection 的特制 chip，而 x86 (即传统 CPU) 并没有针对 C++ 所编译的 machine
code 中的 new/exception-handling/memory allocation/late-binding 作硬件支持
的最佳化动作。

拜 VLSI 之赐，memory allocation 以及 garabage collection 的动作可交由硬件
来实作。在 modem 或电视中，用以数字模拟转换的 DSP (数字讯号处理) chip 而言
，有所谓的 bit-reverse (作 FFT [快速傅立叶转换] 用的)，倘若以一般 x86 来做
这个动作，起码慢 10 倍以上。又如以往的浮点运算，比整数运算慢了 20 ~ 30 倍
，但因有了浮点加速器的出现，浮点运算的速度可为整数运算的 1.3 倍！

前述提到将 JVM 以 co-processor 形式实作的方式，可以参考 Nazomi Communica-
tions [2] 公司的产品，他们推出一套 Java 加速芯片，这个代号为 JA108 的产品
专门针对 2G/2.5G 或 3G 的手机使用。不需要加装额外的内存，只需将这 JA 208
IC 植入原有系统设计中，便可大幅提升 Java 应用程序效率达 15 至 60 倍。
[2] http://www.nazomi.com/

接着，笔者在 Pentium III 上运作 MS-Windows 2000 进行以下实验：(原始码与
machine code 的对照)

c++ 的 virtaul method calling：
┌──────────────────────────┐
│21: testx -> setx(20); // testx 是一个指针对象                          │
│──────────────────────────│
│00401091 push 00000014                                                       │
│00401093 mov eax,dword ptr [testx]                                        │
│00401096 mov eax,dword ptr [eax]                                          │
│00401098 mov ecx,dword ptr [testx]                                        │
│0040109b call dword ptr [eax]                                                   
└──────────────────────────┘
不算 argument 4 个指令

c 的一般 call：
┌───────────────────────────┐
│ good() │
│───────────────────────────│
│0040109f call @ILT+0(?good@@YAXH@Z) (00401000) │
│004010a4 add esp,00000004 │
└───────────────────────────┘
不算 argument 2 个指令

java 的 virtual call：
┌───────────────────────────┐
│my.getData(33); │
│───────────────────────────│
│ aload_2 │
│ bipush 33 │
│ invokevirtual #9 <Method my.getData(I)I> │
└───────────────────────────┘
不算 argument 2 个指令.

c++ 的 constructor：
┌────────────────────────────┐
│test *testx = new test(); │
│────────────────────────────│
│00401056 push 00000008 │
│00401058 call ??2@YAPAXI@Z (00401184) │
│0040105d add esp,00000004 │
│00401060 mov dword ptr [ebp-0c],eax │
│00401063 cmp dword ptr [ebp-0c],00000000 │
│00401067 je main+00000030 (0040107d) │
│0040106d mov ecx,dword ptr [ebp-0c] │
│00401070 call @ILT+15(??0test@@QAE@XZ) (0040100f)│
│00401075 mov dword ptr [testx],eax │
│00401078 jmp main+00000037 (00401084) │
│0040107d mov dword ptr [testx],00000000 │
└────────────────────────────┘
11 个指令

C++ destructor：
┌───────────────────────────┐
│delete testx; │
│───────────────────────────│
│004010a7 mov eax,dword ptr [testx] │
│004010aa mov dword ptr [ebp-10],eax │
│004010ad mov eax,dword ptr [ebp-10] │
│004010b0 mov dword ptr [ebp-14],eax │
│004010b3 mov eax,dword ptr [ebp-14] │
│004010b6 push eax │
│004010b7 call ??3@YAXPAX@Z (00401194) │
│004010bc add esp,00000004 │
└───────────────────────────┘
8 个指令

java 的 constructor：
┌───────────────────────────┐
│my my1 = new my(); │
│───────────────────────────│
│new #2 <Class my> │
│invokenonvirtual #11 <Method my.<init>()V> │
└───────────────────────────┘
2 个指令

由此可发现，对动态配置对象的操作而言，Java 一个 method call 只要一个
machine code，但用 x86 相对需要 4 个，这是 Java 在指令集层面直接支持所致。
我们显而易见 Java 的一个优势 ?─ 目的码很小，可轻易置于资源困窘的家电设备
中，再加上许多现成的 APIs 可进行呼叫、继承的使用，简洁的程序代码就可发挥强大
的力量。

■ 执行引擎

Java VM 的核心是执行引擎，其行为模式依据指令集的定义，JLS (Java Language
Specification) 详细规范了当执行 bytecode 指令会作什么动作，但并未规范如何
实作，因为这是实作者的责任。执行时期，执行引擎以执行绪 (thread) 的形式存在
，如此的执行绪可直译 bytecode 或间接的透过 JIT Compiler 来产生 native code
。执行引擎会依序从 bytecode 中取出 opcode 与 operant，依据 JLS 规范执行相
关动作，接着再取下一个 opcode，直到 method 返回或是丢出 exception。这部份
笔者不打算提太多，因为市面已经有颇多优秀的书籍可供参考，列个书目作参考：

探讨一般性的 Java VM 运作机制：
1.《Java Virtual Machine》 O''Reilly 出版
作者：Jon Meyer & Troy Dwning
有中译本：《Java 虚拟机器》，由国内 Java 权威蔡学镛所译
2.《Inside the Java 2 Virtual Machine》 McGraw-Hill 出版
作者：Bill Venners
如果觉得上一本过于抽象，那 Venners 写的这本书应该很合您胃口，阅读时请
搭配书附光盘，有交互式 Java Applet 解说书中的 JVM 概念，作者的网页 [3]
相当丰富的资料整理。本书虽有中文翻译本，但强烈建议别花冤枉钱，因为谬误
百出。
[3] http://www.artima.com/insidejvm/resources/

专注于嵌入式 JVM 设计：
《深入嵌入式Java虚拟机器－Inside KVM》
作者：胡岳伟 (Mango Hu)
几乎是世面上唯一本探讨 Java KVM 实作的书籍，的确是相当宝贵的参考。不过
，需要留意的是，作者直接挖出 KVM 的原始程序代码，是否经过充分授权，值得
商榷。

■ Java VM 效能探讨

目前商业 Java VM 效能最突出的产品是 BEA 的 JRockit [4]。JRockit 主要对
server-side 应用做了很多改进，并且 Intel 协助 IA32 与 IA64 平台的最佳化，
于是，在多项 benchmark上 (SPECjbb 和 SPECjAppServer) 上，JRockit 遥遥领先
群雄。BEA 是一家引领 J2EE 技术的重量级厂商，在 Enterprise 领域除了优越的技
术外，当然要有强健高效能的 Java VM，于是 BEA 就买下 JRockit了，在许多高阶
应用都可见到 JRockit VM 的踪迹。BEA 网站上有篇由 Joakim Dahlstedt 执笔的文
章，阐述 Java VM 的效能表现其实可以打破许多人眼镜的：[Java - A Slow
Language? It Depends on What You''re Talking About] [5]。
[4] http://www.jrockit.com/
[5] http://dev2dev.bea.com/products/wljrockit81/articles/Dahlstedt.jsp

Joakim Dahlstedt 的来头可不小，是 JRockit VM 的主要设计者，现任 BEA System
里头 Java Runtime Group 的技术长，这篇文章并非老王卖瓜，相反的，Joakim 要
我们明了，评断 Java VM "benchmark" (效能评比) 的方式需要调整，主要是基于以
下几项：

1.一般的 benchmark 比较仅仅是 micro-benchmark level，不能推广到 system-
level。
2.软件产业开发方式发生了很大的变化，大量使用 class library、framework、
Application server，乃至 Web services。援引旧的 benchmark 仅能针对其中
个别 software stack，却不能进行 system-level 的全面分析，如此的衡量本
身就有问题。
3.Java VM 本身的 Dynamic Optimization，可依据最真实的 profiling 数据调整
组件，使其针对效能进行重组。
4.最后，新的 CPU 架构，像是 Intel EPIC 可能更适合于 Dynamic Optimization
，而非传统 static compiler。在 EPIC 的架构下，compiler 对效能的影响相
当大，compiler 有责任选择平行处理的指令集，而非像传统 Pentium 引入自动
的 out-of-order 乱序执行支持，这意味着，软件支配了 EPIC 的效能，这对
static compiler 是不利的，因为仅能从 bytecode 取得固定的统计与符号，却
未能对真实 profiling 作规划。

Joakim 的结论给予我们很好的启发：

"In conclusion, ..., but I hope I''ve convinced you that using runtime
systems like Sun Microsystems'' HotSpot or BEA WebLogic JRockit Java
is not slow or inefficient, and that the performance of a large-scale
system built with Java may be superior to that of the same system
built using C."

IBM 的 JDK 曾经一度是最佳性能的 Java VM，但 Sun JDK 1. 4的性能已与 IBM JDK
1.3 相当，其 server 版采用更积极的 JIT 和 GC (Garbage Collection) 技术，尤
其是针对 SMP 的应用提供最适合该硬件架构与多执行绪处理的 GC。

在另一方面，IBM 将内部的 Jalapeno JVM 研究计划 [6] 的成果以 Open Source 授
权释出的 JikesRVM 计划 [7]，提供一个测试许多 JIT 与 GC 等技术与算法的参
考实作平台。IBM Rearch 将 JikesRVM 视作 JIT 方面的一个 research infrastru-
cture，在网站上罗列了相当丰富的论文可参考 。笔者参考了 JikesRVM 的研究方向
，认为 JIT Compiler 发展趋势可列出以下：
1. 类似于 Hotspot [8] 整合 base interpreter、profiling，以及 adaptive
compiler 三种技术的途径。
2. 动态 profiling 技术，从简单的 counter-based algorithm 进化到
performance monitoring event。
3. 应用静态 compiler 中更 aggressive 的编译技术 (对 JIT Compiler 而言，
编译时间已是次要问题)，产生最佳化原生码 (native code)。
4. 应用 inter-procedural 分析，例如 escape analysis 可以 remove synchro-
nization 和实施 stack allocation。
5. 参考 Runtime 所获得的信息 (主要是 metadata 和 dynamic allocation)，产
生最佳化原生码。

[6] http://www.research.ibm.com/jalapeno/
[7] http://www-124.ibm.com/developerworks/oss/jikesrvm/
[8] http://java.sun.com/products/hotspot/

接着，我们来看看 Sun 的 Hotspot 技术。提到 Hotspot 不能不提 Henry Massalin
这位先驱，Henry 的博士论文在 Java Glossary 的 HotSpot 的解释 [9] 中被誉为
"the mother of all self-modifying code"，同时，HotSpot 也是 "builds heavily
on work done in a PhD thesis by Henry Massalin"。

[9] http://mindprod.com/jgloss/hotspot.html

Java 最初的实作是透过直译器 (interpreter)，但这并非意味 Java 一定被解译执
行的。早期的 Java VM 的确是逐一指令的解译，因此效能极不理想，于是引入了
JIT 等关键技术，而 HotSpot 可说下个世代的 JIT。据 Sun 官方文献指出，使用
HotSpot 的 Java VM 在 Runtime 时期已经很难分辨 Java bytecode 是否被 JVM 解
释执行了，因为 HotSpot 实际上是把 Java 的bytecode 编译成原生码执行了。

实际上，在 HotSpot 设计中，有两个技术是相当重要的，也就是所谓 dynamic
compilation 和 profiling。HotSpot 对 bytecode 的编译，并非在程序执行前预先
编译的 (这种传统的方式相对而言称为 static compilation)，相反的，是在程序执
行过程中，以 HotSpot 内建的编译器做动态的编译，早期的 JIT(Just In Time) 其
实也是如此的概念，不过没有 HotSpot 来得全面性。

那么，HotSpot 是如何动态编译 Java bytecode 呢?HotSpot 采用一个高度弹性的
设计，内部维护了 Profile Monitor，专门监视程序执行中，判断程序片段中使用的
频率高寡，并依据对性能影响的程度，交付于若干算法处理。HotSpot 对于那些对
程序执行时效率影响较大的程序代码片段，特称为 hot spot (特别以小写书写，避免
与 HotSpot 混淆)，HotSpot 会这些片段动态编译成原生码，同时，会依据之前
profiling 的结果，对这些原生码进行最佳化，从而提高执行效率。相反的，如果执
行频率较低的程序代码片段，HotSpot 就没必要花时间做动态编译，只需要以直译器执
行即可。

整体而论，在 HotSpot 下，Java bytecode 是以解译的方式被加载到 JavaVM 中，
但是 HotSpot 立刻会依据某些程序代码片段执行的状态，获知其中对效能影响最大的
部分，透过动态编译与最佳化处理，建立原生码，于是，接下来的执行过程中就可获
得相当程度的效能提升。我们可以得知，HotSpot 对 bytecode 的执行有以下三种处
理方式：
- 直译 (不动态编译)
- 部分动态编译
- 依据 profiling 结果做动态编译与最佳化处理
至于程序哪部分只做直译、部分动态编译，以及哪部分做何种最佳化处理，则全程由
Profile Monitor 决定。

采用 dynamic compilation 会比传统的 static compilation 带来什么优点呢？撇
开跨平台需求不论，dynamic compilation 在许多方面优越于传统的途径，特别是
profiling 的能力。过去 static compilation 很难精准的预知程序执行中究竟何处
才是最需要最佳化处理的部分，仅能透过内建的 template 来建构 micro-level 的
最佳化程序代码。相反的，dynamic compilation 可获悉最真实的 profiling 表现，
依据需求动态调整，这在日后处理器逐渐软件化的发展趋势而言，更显得重要，因为
过去硬件的工作逐渐移转到软件来做，compiler optimization 的责任就格外沉重了
，像是前述 Intel EPIC 架构。

另一个典型的例子，称为 method inlining。无论是在 C++ 或是 Java 中，呼叫
(invoke) method 是很消耗系统资源的，系统必须维护堆栈操作，以符合预期的
calling convention。于是，有人提出把原本需要做 method invocation 的处理，
改用 inline 的方式，「嵌入」到原本呼叫的地方，如此一来，就只是单纯的循序执
行，也不会有堆栈操作。但是，method inlining 的方式对 C++ 与 Java 一类的物
件导向语言来说，编译器很难有很好的实作方式，因为需要兼顾对象导向的特征，尤
其是维持 dynamic binding 性质。static compiler 其实可以把 C++/Java 中属性
为 private 与 static 的 method 做 method inlinng，但是一旦有 overridden 或
dynamic binding 时，static compiler 无法得知实际上的执行状况，就会保守的不
予实施 inlining。这个难题，恰好可被 HotSpot 一类 dynamic compilation 的设
计迎刃而解，因为 Profiling Monitor 对 method invocation 的状况可以掌握，当
然可精准的得知 Runtime 中，RTTI (Run-Time Type Identification) 可协助
HotSpot 处理 method inlining，因此，在 server-side 应用这种重复进行某项目
执行时，可获得颇大的效能提升。

Sun 的文献也指出，在某些状况下，Java 的应用程序甚至可比传统的 C 程序还快。

以目前发展而言，JIT Compiler 的成本主要在于 profiling 与 dynamic compila-
tion 两项。理想而言，这两项成本应该视为 constantant time，于是许多研究论文
相继提出，以作为效能改进。特制为 JIT Compiler 使用、精度不需很高的 Java
Runtime profiling 可参考〈A Portable Samplling-Based Profiler for Java
Virtual Machines〉[10]，该论文提出采用 sampling 的方式来做近似分析。而至于
Dynamic compilation 的 overhead 可以用渐进式最佳化的方式来减少，在 Sun 的
HotSpot 白皮书已有详尽的介绍。

[10] http://www.stanford.edu/~jwhaley/papers/javagrande00.pdf

总而言之，Java 效能议题主要分以下层面探讨：

- 一般性
VM 与 JIT 间的互动、bytecode to IR translation、IR to machine IR
translation，以及 code generation/formatting

- 与平台架构无关 (machine-independent) 的最佳化
CSE、loop invariant code motion、inlining、speculative inlining、
method specialization，以及 multiversion code

- 与平台架构相关 (machine-dependent) 的最佳化
Local/Global register allocation、instruction selection、instruction
scheduling，以及 code/data alignment

- Java 语言层面的最佳化
Rangecheck elimination、checkcast/instanceof removal、type propagation
、optimizations enabled due to strong typing

- Garbage Collection
Precise/imprecise/copying/generational/incremental

- 平行向量化处理 (vectorization)
应用 RISC 工作站的平行处理指令，或是如 Intel 提出的 MMX 与 SSE 指令集

■ Linux 平台的 Java VM

在早期的 Sun Java VM 实作中，执行绪的支持主要透过 Green Thread 的 light-
weight thread 实作的，这可以确保 Java VM 在异质性的操作系统仍可有限度的执
行绪支持，然而，这导致效率的低落，毕竟不是直接使用操作系统的 Multi-thread-
ing 机制。

目前 Sun Linux JDK 已用 native thread 改写过，而 Linux 的 multi-threadded
能力在 IBM 等大厂的投入改进，主要有以下两种形式：

1. NGPT ─ Next Generation Posix Threads
将多个 Java thread 映射 (mapping) 到少点 kernael thread

2. NPTL ─ Native Posix Thread Library
将每个 Java thread 映射 (mapping) 到一个 kernel thread，以最佳化
kernel thread

其中，NGPT [11] 是 IBM 的一项 Open Source 计划，衍生自 GNU Pth 计划 [12]，
NGPT 透过 patch Linux Kernel 2.4 与 glibc 的方式来提供支持。NPTL 则是
Linux Kernel 2.6 中重要设计，可参阅〈The Native POSIX Thread Library for
Linux〉[13] 与〈Linux: Native POSIX Threading Library (NPTL)〉[14] 这两份
经典文献。

[11] http://www-124.ibm.com/developerworks/oss/pthreads/
[12] http://www.gnu.org/software/pth/
[13] http://people.redhat.com/drepper/nptl-design.pdf
[14] http://kerneltrap.org/node/view/422

接下来的篇幅，笔者将介绍曾接触过的 Open Source JavaVM 实作。

- Kaffe ( http://www.kaffe.org/ )

Kaffe 算是这个领域中老字号的项目，从 1996 年 Tim Wilkinson 完成最初的架构
至今已经七年历史了。Kaffe 一开始是 Tim Wilkinson 在英国发展的 clean-room
JavaVM 实作，所谓 cleanroom，就是在不参考 Sun JDK 实作的前提下，自行开发另
一个兼容的实作品，那时的 Kaffe 是 BSD-like 授权方式释出的。1997 年，Tim
Wilkinson 与 Peter Mehlitz 创立一家专注于 JavaVM 实作的公司，Transvirtual
Technologies (TVT)，成功的把 Kaffe 商业化，从那时候开始，Kaffe 有两个版本
：一个是 GPL 授权的 Open Source 实作，也就是 Kaffe.org，另外则是 TVT 内部
维护的 Custom Edition，奠定了 Open Source 与商业发展的典范。

Kaffe VM 设计的理念在于高度的移植能力以及开放 (clean-room 实作，不必受限于
Sun 的发行授权) 发展，由于 Transvirtual Kaffe 的成功，许多以 KaffeVM 为基
础的研究项目相继提出，让许多崭新的概念可藉由 Kaffe 实现。KaffeVM 的移植能
力有多好呢？已经证实能支持 70 余种平台，甚至包含 JIT 引擎。

Transvirtual Technologies 在 1997 年成立以来，就一直活跃于嵌入式装置的领域
，而在 2000 年开始更将其开发的 Kaffe VM 整合 Debian Linux，设计出一个称为
PocketLinux 的平台，其核心架构就是 Linux 和 Kaffe VM (特称 Language Engine
)，上面跑的，可都是货真价实的 Java 程序。PocketLinux 是个相当特殊的操作系
统，以 GNU Debian/Linux 为主架构，上跑 Kaffe VM 与 3rd-party open source
library 的整合环境，为手持装置提供 Web Browser、Synchronization、Media
Player，以及 peer-to-peer 解决方案，此外，PocketLinux 另一个特点就是透过
XML 把 Kaffe 与 Linux 系统服务进行包装，开发者只需要透过 XML 就可以呼叫系
统提供的功能。

尽管是针对手持装置，Kaffe VM 算是最接近完整功能的 Java VM，几乎能与 JDK
1.2 兼容，也支持 Personal Java 规格，但不支持 J2ME 的 Profiles。Kaffe VM
的定位不仅是 small footprint Java VM，更是全功能的嵌入式 JavaVM，藉此充分
发挥 Java 在分布式环境的威力。

很不幸的，在 2001 年与 2002 年之间，Transvirtual 公司面临极大的转变。首先
是 Kaffe.org 的主要维护者 Edouard Parmelan 在 2001 年去世，该年年尾，Tim
Wilkinson，也就是 Transvirtual 的 CEO 决定离开公司。面临技术人员与资金的瞬
间短缺，Peter Mehlitz 继任 CEO 后，决定放弃 Open Source 发展路线，改变为纯
粹的商业公司，于是，将 PocketLinux 重新命名为 XOE，并且不再 Open Source，
Kaffe.org 顿时成为无人领养的孤儿，停顿于 Kaffe 1.0.6 的版本。然而，Peter
Mehlitz 的举动还是拯救不了公司的财务状况。

在 Transvirtual 解散前夕，员工 Jim Pick <[e-mail]> 在 March 12, 2002
宣布将接手维护 Kaffe.org，并且将致力进行 Kaffe Custom Edition (也称为 Kaffe
Pro) 与 Open Source 版本的整合，呼吁开发者协助下个 release，也就是 1.0.7
的出现。2002 年中，Transvirtual 结束营运，但是不意味着 Kaffe 的没落，相反
的，在 Jim Pick 的领导下，Kaffe.org 成功的获得重生，并且与其它 Open source
java VM 项目共享开发资源，例如 GNU Classpath 与 GCJ。

截至今日，许多重量级的应用程序已经可在 KaffeVM 运作了，例如 JBoss、Tomcat、
Jetty，以及 Eclipse IDE。

- Japhar ( http://www.japhar.org/ )

Japher 实作大部分的 JDK 1.1 特征，但不包含 JIT Compiler。自 June 19, 2002
释出 0.11 版后，就没有发展了，原本的开发者转换到 GNU Classpath 项目。

- GNU Classpath ( http://www.classpath.org )

发起于 1998 年的 GNU Classpath 在今日已经成为许多 Open Source JavaVM 项目
的标准。GNU Classpath 事实上并非 Java VM，而是提供 Java VM 所需要的 API 实
作，GNU Classpath 的地位之于 Java VM，好比 libc 之于 C 程序。在 2000 年前
，GNU Classpath 一开始 (0.00 版) 只支持 Japhar，并且开发相当迟缓，几乎同一
个时间，RedHat/Cygnus 发起 GCJ (GCC for Java) 的项目，许多开发者的努力开始
进行整合。随后 Mark Wielaard 接任维护者的重任后，GNU Classpath 的趋近成熟
，Classpath::JVM [13] 有份目前采纳 GNU Classpath 成果的项目清单。

[13] http://www.gnu.org/software/classpath/stories.html

- GNU GCJ (GCC for Java, http://gcc.gnu.org/java/ )
- ORP (Open Runtime Platform, http://orp.sourceforge.net/ )
- Wonka ( http://www.acunia.com/wonka/ )
- IBM JikesRVM ( http://www-124.ibm.com/developerworks/oss/jikesrvm/ )

IBM JikesRVM 衍生是内部的研究计划，Jalapeno。Jalapeno 是建构于 AIX/PowerPC
、Linux/PowerPC、OS X/PowerPC，以及 Linux/IA-32 等平台的实验性 Java VM 实
作，尔后，IBM 将内部 Jalapeno JVM 研究计划的成果以 Open Source 授权释出，
并成立的 JikesRVM 计划，提供一个测试许多 JIT 与 GC 等技术与算法的参考实
作平台。JikesRVM 在其架构设计上一直是独树一格，传统的 Java VM 实作上，核心
主要仍以 C/C++ 为主，但是 JikesRVM 的核心除了平台相依的部分外，其它绝大多
数都以 Java 语言实作，也就是说，JikesRVM 可以是 self-contained 的，正如
FAQ 所提及的：

"Jikes RVM is unique in that it is the first self-bootstrapped virtual
machine written entirely in the Java programming language, i.e., its
Java code runs on itself, without requiring a second virtual machine."

在发展前期，JikesRVM 仍使用 IBM 内部的 core Java APIs class library，这部
分并非 Open Source 的，这也令人诟病 IBM 的半调子开放态度。但自从 JikesRVM
2.2.1 开始 (April 7, 2003)，JikesRVM 可直接使用 GNU Classpath 的成果，这也
是说转变一个完全 Open Source 的 Java VM 研究计划。然而，由于 JikesRVM 绝大
部分的核心在建构时，仍需要一个 Java Runtime，所以开发者还需要安装 Sun JDK
一类的非 Open Source Java VM，但最近终于有所改观。自从 2.3.2 版 (March 17,
2004) 开始，我们可以使用 GPL 授权的 KaffeVM 作为 JikesRVM 的 boot-straping
Java VM，这是 Open Source Java VM 另一项成果累积的展示，可参考 JikesRVM
User Guide [14]。

[14] http://www-124.ibm.com/developerworks/oss/jikesrvm/userguide/HTML/
Bootstrapping_with_Kaffe.html

- JamVm ( http://jamvm.sourceforge.net/ )
- JC VM ( http://jcvm.sourceforge.net/ )