利用specJVM98和Java Grande Forum Benchmark suite Benchmark集合对SJVM、IntelORP,Kaffe3种Java虚拟机进行系统测试。在对测试结果进行系统分析的基础上，比较了不同JVM实现对性能的影响和JVM中关键模块对JVM性能的影响，并提出了提高JVM性能的一些展望。
目录
1 Java虚拟机的关键技术
1.1 字节码执行方式
1.2 自动内存管理
2 JVM 性能的分析和比较
2.1 JVM 的选择
2.2 JVM 性能测试
2.3 JVM 性能的分析和比较
3 结语
Java语言的平台无关性、安全性、自动内存管理等特性，使Java语言得到广泛的应用。Java虚拟机JVM）是 Java平台的核心，JVM读入Java 类文件并执行类文件中的字节码。在一个平台只要有1 个Java虚拟机就可执行Java程序，实现Java语言的平台无关性。Java的字节码中无影响系统安全的指令，同时，JVM读入类文件时，需要预验证类文件，这两点保证了Java语言的安全性。自动内存管理减轻了Java程序员的负担，提高了应用程序的可靠性。但这些特性，使Java的性能受到了一定的影响。字节码执行方式（Execute Engine）和自动内存管理是影响 Java 虚拟机性能的关键模块。本文通过比较几种有代表性的 Java 虚拟机的实现，分析了JVM 中的这2 个关键技术。
1 Java虚拟机的关键技术
1.1 字节码执行方式
最早的Java虚拟机采用的是解释（Interpreter）执行的方式，这种方式效率极低，但JVM的可移植性较好。目前主流的 Java 虚拟机基本采用即时 JIT,Just—In-Time） 编译的方法执行字节码，即将 Java的字节码动态编译为本地的机器码，效率较高，好的JIT 编译效果可以接近 C 语言静态编译的效果。但JIT在执行任何一个方法时，都需要先将该方法编译为本地代码，需要额外的内存存放编译后的本地代码。对于程序中执行频度较低的方法，由于增加了编译的时间，其效率不如解释执行的情况。衡量一个JIT好坏的标准包括编译的代码质量、编译的代码大小以及编译的时间这3个方面。自适应优化（Adap-tive Optimization）是字节码执行的第3 种方式，其实质是混合执行（Mixed code execute）。自适应优化在第1次调用一个方法时，先采用解释执行的方式，当这个方法的调用达到一定的频度而成为“热点”（Hot spot 的方法后，将该方法编译为本地代码，以后对该方法的调用，直接执行编译后的本地代码。
1.2 自动内存管理
自动内存管理也称为垃圾收集（GC,Garbage Collection） ，其作用是自动回收无用单元的内存空间，释放内存的工作由Java虚拟机自动管理，减轻了应用程序员的负担，避免了Java应用程序的内存泄漏。垃圾收集算法的主要评价标准为吞吐量（Throughput）和停顿时间（Pause time） 2个方面。吞吐量指在程序运行中，非垃圾收集的时间与整个应用程序运行时间的比值，比值越高，垃圾收集算法的整体效率越高。
2 JVM 性能的分析和比较
2.1 JVM 的选择
在本测试中，选择了3 个有代表性的虚拟机实现作为研究的对象。
1） Sun Hotspot Client VM 1.4.1 （SJVM） 【1.是Sun公司提供的针对J2SE平台的虚拟机，采用了自适应优化的字节码执行方式、基于代（Generation）的垃圾收集机制、标记-清除（Mark-Sweep）算法和拷贝算法结合的算法。
2） Intel Open Runtime Platform 1.0.10 （Intel ORP 2.是Intel公司提供的Java 虚拟机，提供了针对IA32架构优化的JIT编译器，采用增量式的Train垃圾收集算法。
3）Kaffe 1.0.73.是开放源代码的Java虚拟机实现，它支持的平台较多，垃圾收集机制采用了不分代的保守的标记一清除算法，并提供了 JIT 的编译器。
2.2 JVM 性能测试
通过Benchmark集合的测试，能够有效的比较和分析不同JVM实现对性能的影响以及JVM中关键模块对JVM性能的影响。在本测试中，测试用的Benchmark集合为specJVM98【4】和Java Grande Forum Benchmark suite5.specJVM98采用的是接近真实的应用程序，主要包括Db、Compress、Jess、Javac、Mep-gaudio、Mtrt、Jack7个应用程序。Java Grande Forum Benchmark （以下简称JGF）包括3个部分的测试，第1部分为基本的底层操作，包括算术、赋值、方法调用、异常处理等；第2部分为核心的操作，包括加密、堆排序、矩阵相乘等算法；第3部分为大规模的应用程序，包括了Alpha-beta剪枝搜索、RayTracer等算法。本测试采用的操作系统为Red Hat Linux 7.3.硬件平台为AMD Athlon 1700+，内存256M。图1为specJVM98的测试结果，图2 至图4为JGF3个部分的测试结果。
2.3 JVM 性能的分析和比较
在Java虚拟机中影响性能的模块主要是即时编译和垃圾收集这两个模块。即时编译模块的性能包括编译时间和编译后代码质量两方面。垃圾收集模块主要从吞吐量和停顿时间2 个方面来衡量。
从图1可以看出，Kaffe虚拟机的性能较差，除了第一项测试compress接近SJVM和Intel ORP的性能外，其它测试中的性能表现低于另2个虚拟机的一半。Intel ORP在Compress, Mepgaudio2项测试中要略高于SJVM，而SJVM的性能在其他测试中表现最好。因此，从specJVM98的测试结果来看，SJVM的虚拟机表现最好，Intel ORP的性能较接近SJVM, Kaffe的性能与这两者间有一定的差距。
从图2、图3、图4可以看出：对于JGF基本底层和核心部分的测试，Intel ORP和SJVM的性能相差不大，Kaffe 的性能都低于前两者；对于大规模应用程序的测试，SJVM 的性能远好于 Intel ORP 和Kaffe，而Intel ORP的性能好于Kaffe，这个程序的详细运行结果见表1。
从表1可以看出：Kaffe 的 GC 时间为Intel ORP 的4.79 倍，非GC （大部分为JIT） 时间为Intel ORP的27.87%，非GC时间占整个运行时间的6.40%； Kaffe与Intel ORP相比，大部分的时间花费在JIT编译上； Intel ORP的GC时间为SJVM的25.77倍，非GC时间为SJVM的1.26倍；GC时间占整个运行时间的45.95%。
从以上分析可以看出：
1） SJVM的整体性能是最好的，大部分的性能高于Kaffe和Intel ORP，尤其是在JGF大规模应用程序的测试部分，它的性能远远高于Kaffe和Intel ORP。这是由于字节码执行方式采用了自适应优化的算法，只编译最常用的“热点”方法，同时编译的代码质量较高。
2） SJVM垃圾收集机制较好，也是其性能高于其它两个JVM的关键原因。Intel ORP的即时编译较好，接近SJVM采用的自适应优化的算法，但垃圾收集表现较差，在测试中，一些Benchmark的程序未能正确运行，其语言支持不好。
3） Kaffe的性能表现比较差，主要原因是由于即时编译较差，同时垃圾收集机制的算法也较粗糙。
3 结语
JIT 编译和垃圾收集模块是 JVM 中影响性能的关键模块。JIT 编译的实现与体系结构的关系密切，实现时应充分考虑体系结构的影响，针对目标平台优化。垃圾收集机制的平台相关性较小，实现垃圾收集时，考虑较多的是算法上的提高。当然，不同平台上的内存管理机制还是有差别的，如不同平台上实现虚拟内存的方式、实现cache的方式都有可能不同，这也是提高一个特定平台上垃圾收集机制时需要考虑的因素。
