/ java VM l展
Jim Huang <jimchyun @ ccns.ncku.edu.tw>
<jserv @ kaffe.org>
略檎砉P者 Java VM 作的心得，cT位分享，在本文後半部Ｗ㈧度舾
Open Source Java VM ０傅奶接，P者本身是 KaffeVM [1] _l者，很希望本文
http://www.gaodaima.com/41427.html浅谈JAVA VM 发展
能促挠兴助，更期待您的硇胖附蹋逵杉夹g交流， KaffeVM 有更好的l
展。
[1] http://www.kaffe.org/
■ jvm (Java Virtual Machine) c Java gw
Java VM 橐M的平台，把@平台加以硬w作，即 materialized 後，就是
Java chip。碚f，它就是一w真r的 CPU，假若我不需完整 CPU }s的
O，一涌梢⑺ co-processor，如此一恚筒豁要在 x86 或 Sun Sparc
上用 Java VM 砟M，而是直接把 Java bytecode「jo」Java chip 上绦小＿@
就是早先 Sun Q picoJava 的技g，然，S著各硬wS商的投入，引入更}
s的技g，但原t上^念是一致的。
「模M」既然非真，然在效率上就^吃了，所以就常o人 Java 绦谐⒊
Y源的印象，其那是指 Virtual Machine 的效能。榱烁倪M JVM 效能，使用S多
技g加速，其中最重要的莫如 JIT (Just In Time) Compiler (及rg器，注意：
不要跟「即r」[realtime] 搞混) c HotSpot 的 Adaptive Compiler 等 dynamic
compilation 技g。
Java Chip 是 Optimized for Java 的 OOP、exption-handling、memory/garbage
collection 的特u chip，而 x86 (即鹘y CPU) K]有 C++ 所g的 machine
code 中的 new/exception-handling/memory allocation/late-binding 作硬w支援
的最佳化幼鳌
拜 VLSI 之n，memory allocation 以及 garabage collection 的幼骺山挥捎搀w
作。在 modem 或中，用以滴活比DQ的 DSP (滴挥) chip 而言
，有所^的 bit-reverse (作 FFT [快速傅立~DQ] 用的)，倘若以一般 x86 碜
@幼鳎鸫a慢 10 倍以上。又如以往的浮c/算，比整颠/算慢了 20 ~ 30 倍
，但因有了浮c加速器的出F，浮c/算的速度可檎颠/算的 1.3 倍！
前述提到 JVM 以 co-processor 形式作的方式，可以⒖ Nazomi Communica-
tions [2] 公司的a品，他推出一套 Java 加速晶片，@代 JA108 的a品
ｉT 2G/2.5G 或 3G 的手C使用。不需要加b~外的w，只需⑦@ JA 208
IC 植入原有系yO中，便可大幅提升 Java 贸淌叫蔬_ 15 至 60 倍。
[2] http://www.nazomi.com/
接著，P者在 Pentium III 上/作 MS-Windows 2000 M行以下：(原始ac
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 指令
由此可lF，B配置物件的操作而言，Java 一 method call 只要一
machine code，但用 x86 相π枰 4 ，@是 Java 在指令集用嬷苯又г隆
我@而易 Java 的一 ―─ 目的a很小，可p易置於Y源困窘的家O
中，再加上S多F成的 APIs 可M行呼叫、^承的使用，的程式a就可l]大
的力量。
■ 绦幸
Java VM 的核心是绦幸妫湫槟Ｊ揭噶罴亩x，JLS (Java Language
Specification) 了绦 bytecode 指令魇颤N幼鳎K未如何
作，因檫@是作者的任。绦r期，绦幸嬉绦芯w (thread) 的形式存在
，如此的绦芯w可直g bytecode 或g接的透^ JIT Compiler 懋a生 native code
。绦幸佬 bytecode 中取出 opcode c operant，依 JLS 绦邢
P幼鳎又偃∠乱 opcode，直到 method 返回或是G出 exception。@部份
P者不打算提太多，因槭忻嬉呀有H多秀的晒⒖迹孔⒖迹
探一般性的 Java VM /作C制：
1.《Java Virtual Machine》 O’Reilly 出版
作者：Jon Meyer & Troy Dwning
有中g本：《Java MC器》，由 Java 嗤WO所g
2.《Inside the Java 2 Virtual Machine》 McGraw-Hill 出版
作者：Bill Venners
如果X得上一本^於抽象，那 Venners 的@本很合您胃口，xr
搭配焦獾谢邮 Java Applet 解f械 JVM 概念，作者的W [3]
相S富的Y料整理。本m有中文翻g本，但烈建he花冤枉X，因橹`
百出。
[3] http://www.artima.com/insidejvm/resources/
Ｗ㈧肚度胧 JVM O：
《深入嵌入式JavaMC器－Inside KVM》
作者：胡岳 (Mango Hu)
乎是世面上唯一本探 Java KVM 作的拇_是相F的⒖肌２贿^
，需要留意的是，作者直接挖出 KVM 的原始程式a，是否^充分授啵档
商榷。
■ Java VM 效能探
目前商I Java VM 效能最突出的a品是 BEA 的 JRockit [4]。JRockit 主要
server-side 米隽撕芏喔倪M，K且 Intel f助 IA32 c IA64 平台的最佳化，
於是，在多 benchmark上 (SPECjbb 和 SPECjAppServer) 上，JRockit bbI先
群雄。BEA 是一家引I J2EE 技g的重量S商，在 Enterprise I域除了越的技
g外，然要有健高效能的 Java VM，於是 BEA 就I下 JRockit了，在S多高A
枚伎梢到 JRockit VM 的E。BEA W站上有篇由 Joakim Dahlstedt 坦P的文
章，U述 Java VM 的效能表F其可以打破S多人眼R的：[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 的主要O者，F任 BEA System
e^ Java Runtime Group 的技gL，@篇文章K非老王u瓜，相反的，Joakim 要
我明t，u Java VM "benchmark" (效能u比) 的方式需要{整，主要是基於以
下：
1.一般的 benchmark 比^HH是 micro-benchmark level，不能推V到 system-
level。
2.waI_l方式l生了很大的化，大量使用 class library、framework、
Application server，乃至 web services。援引f的 benchmark H能ζ渲
e software stack，s不能M行 system-level 的全面分析，如此的衡量本
身就有}。
3.Java VM 本身的 Dynamic Optimization，可依钫的 profiling {整
元件，使其π苓M行重M。
4.最後，新的 CPU 架，像是 Intel EPIC 可能更m合於 Dynamic Optimization
，而非鹘y static compiler。在 EPIC 的架下，compiler π艿挠绊相
大，compiler 有任x衿叫刑淼闹噶罴窍鹘y Pentium 引入自
的 out-of-order y序绦兄г@意味著，w支配了 EPIC 的效能，@
static compiler 是不利的，因H能 bytecode 取得固定的yc符，s
未能φ profiling 作。
Joakim 的Yo予我很好的l：
"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的性能已c IBM JDK
1.3 相，其 server 版裼酶eO的 JIT 和 GC (Garbage Collection) 技g，尤
其是 SMP 的锰峁┳钸m合硬w架c多绦芯w淼 GC。
在另一方面，IBM 炔康 Jalapeno JVM 研究 [6] 的成果以 Open Source 授
噌出的 JikesRVM [7]，提供一yS多 JIT c GC 等技gc演算法的
考作平台。IBM Rearch JikesRVM 作 JIT 方面的一 research infrastru-
cture，在W站上_列了相S富的文可⒖ 。P者⒖剂 JikesRVM 的研究方向
，J JIT Compiler l展菘闪谐鲆韵拢
1. 似於 Hotspot [8] 整合 base interpreter、profiling，以及 adaptive
compiler 三N技g的途。
2. B profiling 技g，蔚 counter-based algorithm M化到
performance monitoring event。
3. 渺oB compiler 中更 aggressive 的g技g ( JIT Compiler 而言，
grg已是次要})，a生最佳化原生a (native code)。
4. inter-procedural 分析，例如 escape analysis 可以 remove synchro-
nization 和施 stack allocation。
5. ⒖ Runtime 所@得的Y (主要是 metadata 和 dynamic allocation)，a
生最佳化原生a。
[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 技g。提到 Hotspot 不能不提 Henry Massalin
@位先，Henry 的博士文在 Java Glossary 的 HotSpot 的解 [9] 中被u
"the mother of all self-modifying code"，同r，HotSpot 也是 "builds heavily
on work done in a PhD thesis by Henry Massalin"。
[9] http://mindprod.com/jgloss/hotspot.html
Java 最初的作是透^直g器 (interpreter)，但@K非意味 Java 一定被解g
行的。早期的 Java VM 的_是逐一指令的解g，因此效能O不理想，於是引入了
JIT 等PI技g，而 HotSpot 可f下世代的 JIT。 Sun 官方文I指出，使用
HotSpot 的 Java VM 在 Runtime r期已很y分辨 Java bytecode 是否被 JVM 解
绦辛耍 HotSpot H上是把 Java 的bytecode g成原生a绦辛恕
H上，在 HotSpot O中，有技g是相重要的，也就是所^ dynamic
compilation 和 profiling。HotSpot bytecode 的g，K非在程式绦星邦A先
g的 (@N鹘y的方式相Χ苑Q static compilation)，相反的，是在程式
行^程中，以 HotSpot 冉ǖ木g器做B的g，早期的 JIT(Just In Time) 其
也是如此的概念，不^]有 HotSpot 淼萌嫘浴
那N，HotSpot 是如何Bg Java bytecode 呢tHotSpot 裼靡高度性的
O，炔烤So了 Profile Monitor，ｉTO程式绦兄校喑淌狡沃惺褂玫
l率高寡，K依π阅苡绊的程度，交付於若干演算法怼HotSpot 赌切
程式绦r效率影^大的程式a片段，特Q hot spot (特e以小，避免
c HotSpot 混淆)，HotSpot @些片段Bg成原生a，同r，
profiling 的Y果，@些原生aM行最佳化，而提高绦行省Ｏ喾吹模绻
行l率^低的程式a片段，HotSpot 就]必要花rg做Bg，只需要以直g器
行即可。
整w而，在 HotSpot 下，Java bytecode 是以解g的方式被d入到 JavaVM 中，
但是 HotSpot 立刻承┏淌酱a片段绦械B，@知其中π苡绊最大的
部分，透^Bgc最佳化恚⒃a，於是，接下淼绦羞^程中就可@
得相程度的效能提N。我可以得知，HotSpot bytecode 的绦杏幸韵氯N
理方式：
– 直g (不Bg)
– 部分Bg
– 依 profiling Y果做Bgc最佳化
至於程式哪部分只做直g、部分Bg，以及哪部分做何N最佳化恚t全程由
Profile Monitor Q定。
裼 dynamic compilation 鹘y的 static compilation 硎颤Nc呢？撇
_跨平台需求不，dynamic compilation 在S多方面越於鹘y的途，特e是
profiling 的能力。^去 static compilation 很y精实念A知程式绦兄芯烤购翁
才是最需要最佳化淼牟糠郑H能透^冉ǖ template 斫 micro-level 的
最佳化程式a。相反的，dynamic compilation 可@悉最真的 profiling 表F，
依枨B{整，@在日後砥髦uw化的l展荻裕@得重要，因
^去硬w的工作逐u移D到w碜觯compiler optimization 的任就格外沈重了
，像是前述 Intel EPIC 架。
另一典型的例子，Q method inlining。o是在 C++ 或是 Java 中，呼叫
(invoke) method 是很消耗系yY源的，系y必So堆B操作，以符合A期的
calling convention。於是，有人提出把原本需要做 method invocation 的恚
改用 inline 的方式，「嵌入」到原本呼叫的地方，如此一恚椭皇渭的循序
行，也不卸询B操作。但是，method inlining 的方式 C++ c Java 一的物
件蛘Z言碚f，g器很y有很好的作方式，因樾枰骖物件虻奶蒯纾
其是S持 dynamic binding 性|。static compiler 其可以把 C++/Java 中傩
private c static 的 method 做 method inlinng，但是一旦有 overridden 或
dynamic binding r，static compiler o法得知H上的绦r，就Ｊ氐牟
予施 inlining。@y}，恰好可被 HotSpot 一 dynamic compilation 的O
迎刃而解，因 Profiling Monitor method invocation 的r可以掌握，
然可精实牡弥 Runtime 中，RTTI (Run-Time Type Identification) 可f助
HotSpot method inlining，因此，在 server-side 眠@N重}M行某目
绦r，可@得H大的效能提N。
Sun 的文I也指出，在某些r下，Java 的贸淌缴踔量杀鹘y的 C 程式快。
以目前l展而言，JIT Compiler 的成本主要在於 profiling c dynamic compila-
tion 身。理想而言，@身成本 constantant time，於是S多研究文
相^提出，以作樾芨倪M。特u JIT Compiler 使用、精度不需很高的 Java
Runtime profiling 可⒖肌A Portable Samplling-Based Profiler for Java
Virtual Machines〉[10]，文提出裼 sampling 的方式碜鼋品治觥６领
Dynamic compilation 的 overhead 可以用uM式最佳化的方式p少，在 Sun 的
HotSpot 白皮延性M的介B。
[10] http://www.stanford.edu/~jwhaley/papers/javagrande00.pdf
而言之，Java 效能h}主要分以下用嫣接：
– 一般性
VM c JIT g的互印bytecode to IR translation、IR to machine IR
translation，以及 code generation/formatting
– c平台架oP (machine-independent) 的最佳化
CSE、loop invariant code motion、inlining、speculative inlining、
method specialization，以及 multiversion code
– c平台架相P (machine-dependent) 的最佳化
Local/Global register allocation、instruction selection、instruction
scheduling，以及 code/data alignment
– Java Z言用娴淖罴鸦
Rangecheck elimination、checkcast/instanceof removal、type propagation
、optimizations enabled due to strong typing
– Garbage Collection
Precise/imprecise/copying/generational/incremental
– 平行向量化 (vectorization)
RISC 工作站的平行碇噶睿蚴侨 Intel 提出的 MMX c SSE 指令集
■ linux 平台的 Java VM
在早期的 Sun Java VM 作中，绦芯w的支援主要透^ Green Thread 的 light-
weight thread 作的，@可以_保 Java VM 在|性的作I系y仍可有限度的
行w支援，然而，@е滦实牡吐洌竟不是直接使用作I系y的 Multi-thread-
ing C制。
目前 Sun Linux JDK 已用 native thread 改^，而 Linux 的 multi-threadded
能力在 IBM 等大S的投入改M，主要有以下煞N形式：
1. NGPT ─ Next Generation Posix Threads
⒍ Java thread 映射 (mapping) 到少c 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 c glibc 的方式硖峁┲гNPTL t是
Linux Kernel 2.6 中重要O，可㈤〈The Native POSIX Thread Library for
Linux〉[13] c〈Linux: Native POSIX Threading Library (NPTL)〉[14] @煞
典文I。
[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
接下淼钠P者⒔榻B曾接|^的 Open Source JavaVM 作。
– Kaffe ( http://www.kaffe.org/ )
Kaffe 算是@I域中老字的０福 1996 年 Tim Wilkinson 完成最初的架
至今已七年v史了。Kaffe 一_始是 Tim Wilkinson 在英l展的 clean-room
JavaVM 作，所^ cleanroom，就是在不⒖ Sun JDK 作的前提下，自行_l另
一相容的作品，那r的 Kaffe 是 BSD-like 授喾绞结出的。1997 年，Tim
Wilkinson c Peter Mehlitz 立一家Ｗ㈧ JavaVM 作的公司，Transvirtual
Technologies (TVT)，成功的把 Kaffe 商I化，那r候_始，Kaffe 有版本
：一是 GPL 授嗟 Open Source 作，也就是 Kaffe.org，另外t是 TVT 炔
So的 Custom Edition，奠定了 Open Source c商Il展的典。
Kaffe VM O的理念在於高度的移植能力以及_放 (clean-room 作，不必受限於
Sun 的l行授) l展，由於 Transvirtual Kaffe 的成功，S多以 KaffeVM 榛
A的研究０赶嗬^提出，S多湫碌母拍羁山逵 Kaffe F。KaffeVM 的移植能
力有多好呢？已C能支援 70 NN平台，甚至包含 JIT 引擎。
Transvirtual Technologies 在 1997 年成立以恚鸵恢被钴S於嵌入式b置的I域
，而在 2000 年_始更⑵溟_l的 Kaffe VM 整合 Debian Linux，O出一Q
PocketLinux 的平台，其核心架就是 Linux 和 Kaffe VM (特Q Language Engine
)，上面跑的，可都是真r的 Java 程式。PocketLinux 是相特殊的操作系
y，以 GNU Debian/Linux 橹骷，上跑 Kaffe VM c 3rd-party open source
library 的整合h境，槭殖盅b置提供 Web Browser、Synchronization、Media
Player，以及 peer-to-peer 解Q方案，此外，PocketLinux 另一特c就是透^
xml 把 Kaffe c Linux 系y服者M行包b，_l者只需要透^ XML 就可以呼叫系
y提供的功能。
管是κ殖盅b置，Kaffe VM 算是最接近完整功能的 Java VM，乎能c JDK
1.2 相容，也支援 Personal Java 瘢恢г J2ME 的 Profiles。Kaffe VM
的定位不H是 small footprint Java VM，更是全功能的嵌入式 JavaVM，藉此充分
l] Java 在分散式h境的威力。
很不幸的，在 2001 年c 2002 年之g，Transvirtual 公司面RO大的D。首先
是 Kaffe.org 的主要So者 Edouard Parmelan 在 2001 年去世，年年尾，Tim
Wilkinson，也就是 Transvirtual 的 CEO Q定x_公司。面R技g人TcY金的瞬
g短缺，Peter Mehlitz ^任 CEO 後，Q定放 Open Source l展路，改榧
粹的商I公司，於是， PocketLinux 重新命名 XOE，K且不再 Open Source，
Kaffe.org Dr成o人IB的孤海ｎD於 Kaffe 1.0.6 的版本。然而，Peter
Mehlitz 的e舆是拯救不了公司的r。
在 Transvirtual 解散前夕，T工 Jim Pick <[email protected]> 在 March 12, 2002
宣布⒔邮志So Kaffe.org，K且⒅铝M行 Kaffe Custom Edition (也Q Kaffe
Pro) c Open Source 版本的整合，呼n_l者f助下 release，也就是 1.0.7
的出F。2002 年中，Transvirtual Y束I/，但是不意味著 Kaffe 的]落，相反
的，在 Jim Pick 的I拢Kaffe.org 成功的@得重生，K且c其他 Open source
java VM ０腹蚕黹_lY源，例如 GNU Classpath c GCJ。
截至今日，S多重量的贸淌揭呀可在 KaffeVM /作了，例如 JBoss、Tomcat、
Jetty，以及 Eclipse IDE。
– Japhar ( http://www.japhar.org/ )
Japher 作大部分的 JDK 1.1 特徵，但不包含 JIT Compiler。自 June 19, 2002
出 0.11 版後，就]有l展了，原本的_l者DQ到 GNU Classpath ０浮
– GNU Classpath ( http://www.classpath.org )
l起於 1998 年的 GNU Classpath 在今日已成樵S多 Open Source JavaVM ０
的省GNU Classpath 事上K非 Java VM，而是提供 Java VM 所需要的 API
作，GNU Classpath 的地位之於 Java VM，好比 libc 之於 C 程式。在 2000 年前
，GNU Classpath 一_始 (0.00 版) 只支援 Japhar，K且_l相t乎同一
rg，RedHat/Cygnus l起 GCJ (GCC for Java) 的０福S多_l者的努力_始
M行整合。S後 Mark Wielaard 接任So者的重任後，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 授噌出，
K成立的 JikesRVM ，提供一yS多 JIT c GC 等技gc演算法的⒖
作平台。JikesRVM 在其架O上一直是湟桓瘢鹘y的 Java VM 作上，核心
主要仍以 C/C++ 橹鳎 JikesRVM 的核心除了平台相依的部分外，其他^大多
刀家 Java Z言作，也就是f，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."
在l展前期，JikesRVM 仍使用 IBM 炔康 core Java APIs class library，@部
分K非 Open Source 的，@也令人病 IBM 的半{子_放B度。但自 JikesRVM
2.2.1 _始 (April 7, 2003)，JikesRVM 可直接使用 GNU Classpath 的成果，@也
是fD一完全 Open Source 的 Java VM 研究。然而，由於 JikesRVM ^大
部分的核心在建r，仍需要一 Java Runtime，所以_l者需要安b Sun JDK
一的非 Open Source Java VM，但最近K於有所改^。自 2.3.2 版 (March 17,
2004) _始，我可以使用 GPL 授嗟 KaffeVM 作 JikesRVM 的 boot-straping
Java VM，@是 Open Source Java VM 另一成果累e的展示，可⒖ 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/ )
(… 未完…)
欢迎大家阅读《浅谈JAVA VM 发展》,跪求各位点评,若觉得好的话请收藏本文，by 搞代码
转载请注明原文链接：浅谈JAVA VM 发展
