我们看到对于足够大的数据数组中，Java RMI性能优于HPC++、Nexus RMI/HPC++和Nexus RMI。。
更惊人的是：在使用JIT后，Java RMI性能优于HPC++We see that Java RMI outperforms HPC++, Nexus RMI/HPC++, and Nexus RMI
for suciently large data arrays. Since data is pipelined in Java RMI, but not in Nexus RMI, this result
is reasonable. What is more surprising is that when the JIT is enabled, Java RMI is able to outperform
HPC++.作者：
Fabian Breg, Shridhar Diwan, Juan Villacis,
Jayashree Balasubramanian, Esra Akman, Dennis GannonIndiana大学计算机科学系
Department of Computer Science
Indiana University
http://www.cs.ucsb.edu/conferences/java98/papers/rmi.pdf另一个证据：题目：
DEVELOPMENT OF A JAVA-BASED METEOROLOGICAL WORKSTATION BY GERMAN
METEOROLOGICAL SERVICE AND PARTNERS
德国气象服务与伙伴用Java开发气象工作站German Weather Service DWD and German
Military Geophysical Service decided two years ago
to develop a new meteorological workstation from
scratch
德国气象服务局（DWD）与德国军事地球物理服务局决定开发一套全新的气象工作站
.....The performance issue was evaluated before in a pilot project and is
analysed during all phases of development. It
turned out that this is not a problem, however many
things must be considered in the design and during
coding. Even numerical calculatuions are now in
pure Java since we found they can outperform C++
when carefully optimized.
性能问题在一个导航项目开发之前进行了评估。结果是：性能不是问题，但在编码过程中要考虑很多事情。
我们发现：在优化过后，纯Java甚至连数学计算的性能也超过了Ｃ＋＋
http://ams.confex.com/ams/pdfpapers/52402.pdf
再一个证据：
题目：＜＜Is Java ready for computational science?＞＞
＜＜Java为科学计算做好准备了吗？＞＞出处：Computer Science Dept., University of Karlsruhe, Germany
德国Karlsruhe大学计算机科学系
http://www.ubka.uni-karlsruhe.de/vvv/1998/informatik/27/27.pdf.gz
IBM的Java编译器以３：２战胜Fortran 90
Fortran90:Java的结果（单位为秒）
20:14
40:30
440:444
1080:1089
11790:11690
输了的两项是以不到！％的差距输的
而赢了的三项中有两项是以３３％以上的差距获胜的
文章中的结论：Conclusion：
Java will become a major language for computational science.
Java将成为科学计算中的主要语言还有一个证据：
＜＜Real Java for Real Time＞＞
用在实时领域中的真正的java
The best JIT compilers today
generate code that come close to, or in some cases even
outperform, C++ code.
当今最好的ＪＩＴ编译器可以产生性能接近甚至超过C++的代码http://www.lucas.lth.se/publications/pub2002/nilsson_realjavaforrealtime.pdf
三位作者：
Anders Nilsson、Torbjorn Ekman、Klas Nilsson瑞典Lund大学计算机科学系
Dept. of Computer Science
Lund University
SWEDEN
One More证据:
＜＜Java server benchs＞＞
其中对比了Servlet与C/C++写的CGI的各方面的性能结论：
Conclusion:
Java servlets outperform CGI
Java Servlet的性能超过CGI
http://www.research.ibm.com/journal/sj/391/baylor.html
Servlet与CGI的性能对比：
结论：Servlet性能大大超过用Ｃ写的CGI：基准所取得的结果是：
管理 — 为 64 个节点 SP 配置开发和成功地实现了 Java 和 WebSphere 安装和有效的管理过程。
稳定性 — 大规模 WebSphere 配置的稳定性通过烤机测试证明，在这种测试中，64 个节点的 WebSphere 系统，连续 48 小时运行，硬件或软件没有故障或错误。收集的连续 12 小时以上的性能数据表明稳定的吞吐量和 CPU 利用率。
可扩展性 — 在多达 64 个节点的配置中，在低量和高量工作负载的情况下，通过显示几乎线性的吞吐量（页面浏览量/秒/节点数）证明可扩展性。
性能 — Java 和 WebSphere 技术可以 300% 完成规定的目标。当前的 C/CGI 技术，在 CPU 利用率为 37% 时，大约提供 1.3 次页面浏览/秒/节点；CPU 利用率为 30-40% 时，IBM 的 Java 和 WebSphere 技术大约提供 3.8 次页面浏览/秒/节点。CPU 利用率更高时（> 90%），使用 64 个节点的配置能够在平均响应时间小于 2 秒的情况下提供 564 次页面浏览/秒/节点。假设是类似 2000 年 2 月 Schwab 所安装的配置，这种级别的性将能在“市场风暴”（在此期间有大量的请求）中支持 100,000 次并发的最终用户会话。图表见原原文：
http://www-900.ibm.com/developerWorks/cn/wsdd/hvws/Schwab2001.shtml评测报告：.NET的性能仍然远远落后于Java.NET上同样代码的运行速度并不随运行次数的增加而提高，说明.NET CLR只是简单地进行了JIT编译。而在Hotspot Server上，不仅开始时的性能就有优势，而且速度还会不断提高可以看到，随着运行次数的增加，Sun Hotspot Server不断将领先优势拉大，最后几乎比.NET 1.1快了一倍。.NET CLR始终无法将运行时间降低到8秒以下，而Sun Hotspot Server在多次运行之后则可以保持在5秒以下。因此，Cameron认为，对于大运算量的应用程序，Hotspot JVM比Microsoft CLR要快得多。
http://www.5d.cn/bbs/archivecontent.asp?id=792254
结论：Java与Fortran一样快
Java Pro 2002-2003中文精华合集[第1辑]
《Java够快吗》
http://act.it.sohu.com/book/chapter.php?id=51&volume=1&chapter=9
http://act.it.sohu.com/book/serialize.php?id=51
参考文献
J.E. Moreira, et. al.,"The Ninja Project,"
Communications of the ACM, 44(10), 102, (2001).
＜＜ACM通讯＞＞
Z. Budimli, K. Kennedy, and J. Piper,
"The Cost of Being Object-Oriented: A Preliminary Study,"
＜＜科学计算＞＞
Scientific Computing, 7(2), 87, 1999.Zoran Budimli网站的: www.cs.rice.edu/~zoran
这是ＳＵＮ对比J2EE与.net的Bench报告：
J2EE是.net速度的200%
Web Services Performance
http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf
可能第三方的结论会更客观：2004年11月4日最新数据！！！！！！
http://www.shudo.net/jit/perf/
＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆
FFT ， SOR，Monte Carlo， Sparse matmult，LU 这5个Bench的结果：
＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆
C＃.net根本不值一提，0：5 输给java。
在综合比分上，java VS C#=324:240
java大比分领先
至于mono就差的更远了
java以324：163完胜mono再来个证据：Java is quite efficient nowadays, and it is often reported that it can outperform C++ under some circumstances because it can perform run-time optimizationsJava目前效率很高，经常有报告说Java性能高于C++，因为Java能进行运行时的优化
http://www-pw.physics.uiowa.edu/das2/das_qa.htmlSwing GUI图形界面的性能：
在菜单、树形、文本框、table等几项上，jdk1.4.0比jdk1.3.1快４０％到９０％Reflection的性能上，jdk1.4.0比jdk1.3.1快２０倍！快２０倍以上的还包括远程窗口调用其它各项上，jdk1.4.0几乎都比jdk1.3.1快５０％以上，“Java慢”也只是“历史”了
其它各方面的性能提升在此
http://java.sun.com/j2se/1.4/performance.guide.html
ＳＵＮ的数据说明，JDK1.4.2在各方面的性能是jdk1.4.1的５０％到３８０％
可以看到，几乎每次java的版本提高都带来性能的极大提升。所以如果你在某处看到一个bench说Ｃ＋＋比java快，那就很可能是用的老版本的java。
但是Ｃ＋＋近年似乎没什么速度的提升
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html
更惊人的是：在使用JIT后，Java RMI性能优于HPC++We see that Java RMI outperforms HPC++, Nexus RMI/HPC++, and Nexus RMI
for suciently large data arrays. Since data is pipelined in Java RMI, but not in Nexus RMI, this result
is reasonable. What is more surprising is that when the JIT is enabled, Java RMI is able to outperform
HPC++.作者：
Fabian Breg, Shridhar Diwan, Juan Villacis,
Jayashree Balasubramanian, Esra Akman, Dennis GannonIndiana大学计算机科学系
Department of Computer Science
Indiana University
http://www.cs.ucsb.edu/conferences/java98/papers/rmi.pdf另一个证据：题目：
DEVELOPMENT OF A JAVA-BASED METEOROLOGICAL WORKSTATION BY GERMAN
METEOROLOGICAL SERVICE AND PARTNERS
德国气象服务与伙伴用Java开发气象工作站German Weather Service DWD and German
Military Geophysical Service decided two years ago
to develop a new meteorological workstation from
scratch
德国气象服务局（DWD）与德国军事地球物理服务局决定开发一套全新的气象工作站
.....The performance issue was evaluated before in a pilot project and is
analysed during all phases of development. It
turned out that this is not a problem, however many
things must be considered in the design and during
coding. Even numerical calculatuions are now in
pure Java since we found they can outperform C++
when carefully optimized.
性能问题在一个导航项目开发之前进行了评估。结果是：性能不是问题，但在编码过程中要考虑很多事情。
我们发现：在优化过后，纯Java甚至连数学计算的性能也超过了Ｃ＋＋
http://ams.confex.com/ams/pdfpapers/52402.pdf
再一个证据：
题目：＜＜Is Java ready for computational science?＞＞
＜＜Java为科学计算做好准备了吗？＞＞出处：Computer Science Dept., University of Karlsruhe, Germany
德国Karlsruhe大学计算机科学系
http://www.ubka.uni-karlsruhe.de/vvv/1998/informatik/27/27.pdf.gz
IBM的Java编译器以３：２战胜Fortran 90
Fortran90:Java的结果（单位为秒）
20:14
40:30
440:444
1080:1089
11790:11690
输了的两项是以不到！％的差距输的
而赢了的三项中有两项是以３３％以上的差距获胜的
文章中的结论：Conclusion：
Java will become a major language for computational science.
Java将成为科学计算中的主要语言还有一个证据：
＜＜Real Java for Real Time＞＞
用在实时领域中的真正的java
The best JIT compilers today
generate code that come close to, or in some cases even
outperform, C++ code.
当今最好的ＪＩＴ编译器可以产生性能接近甚至超过C++的代码http://www.lucas.lth.se/publications/pub2002/nilsson_realjavaforrealtime.pdf
三位作者：
Anders Nilsson、Torbjorn Ekman、Klas Nilsson瑞典Lund大学计算机科学系
Dept. of Computer Science
Lund University
SWEDEN
One More证据:
＜＜Java server benchs＞＞
其中对比了Servlet与C/C++写的CGI的各方面的性能结论：
Conclusion:
Java servlets outperform CGI
Java Servlet的性能超过CGI
http://www.research.ibm.com/journal/sj/391/baylor.html
Servlet与CGI的性能对比：
结论：Servlet性能大大超过用Ｃ写的CGI：基准所取得的结果是：
管理 — 为 64 个节点 SP 配置开发和成功地实现了 Java 和 WebSphere 安装和有效的管理过程。
稳定性 — 大规模 WebSphere 配置的稳定性通过烤机测试证明，在这种测试中，64 个节点的 WebSphere 系统，连续 48 小时运行，硬件或软件没有故障或错误。收集的连续 12 小时以上的性能数据表明稳定的吞吐量和 CPU 利用率。
可扩展性 — 在多达 64 个节点的配置中，在低量和高量工作负载的情况下，通过显示几乎线性的吞吐量（页面浏览量/秒/节点数）证明可扩展性。
性能 — Java 和 WebSphere 技术可以 300% 完成规定的目标。当前的 C/CGI 技术，在 CPU 利用率为 37% 时，大约提供 1.3 次页面浏览/秒/节点；CPU 利用率为 30-40% 时，IBM 的 Java 和 WebSphere 技术大约提供 3.8 次页面浏览/秒/节点。CPU 利用率更高时（> 90%），使用 64 个节点的配置能够在平均响应时间小于 2 秒的情况下提供 564 次页面浏览/秒/节点。假设是类似 2000 年 2 月 Schwab 所安装的配置，这种级别的性将能在“市场风暴”（在此期间有大量的请求）中支持 100,000 次并发的最终用户会话。图表见原原文：
http://www-900.ibm.com/developerWorks/cn/wsdd/hvws/Schwab2001.shtml评测报告：.NET的性能仍然远远落后于Java.NET上同样代码的运行速度并不随运行次数的增加而提高，说明.NET CLR只是简单地进行了JIT编译。而在Hotspot Server上，不仅开始时的性能就有优势，而且速度还会不断提高可以看到，随着运行次数的增加，Sun Hotspot Server不断将领先优势拉大，最后几乎比.NET 1.1快了一倍。.NET CLR始终无法将运行时间降低到8秒以下，而Sun Hotspot Server在多次运行之后则可以保持在5秒以下。因此，Cameron认为，对于大运算量的应用程序，Hotspot JVM比Microsoft CLR要快得多。
http://www.5d.cn/bbs/archivecontent.asp?id=792254
结论：Java与Fortran一样快
Java Pro 2002-2003中文精华合集[第1辑]
《Java够快吗》
http://act.it.sohu.com/book/chapter.php?id=51&volume=1&chapter=9
http://act.it.sohu.com/book/serialize.php?id=51
参考文献
J.E. Moreira, et. al.,"The Ninja Project,"
Communications of the ACM, 44(10), 102, (2001).
＜＜ACM通讯＞＞
Z. Budimli, K. Kennedy, and J. Piper,
"The Cost of Being Object-Oriented: A Preliminary Study,"
＜＜科学计算＞＞
Scientific Computing, 7(2), 87, 1999.Zoran Budimli网站的: www.cs.rice.edu/~zoran
这是ＳＵＮ对比J2EE与.net的Bench报告：
J2EE是.net速度的200%
Web Services Performance
http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf
可能第三方的结论会更客观：2004年11月4日最新数据！！！！！！
http://www.shudo.net/jit/perf/
＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆
FFT ， SOR，Monte Carlo， Sparse matmult，LU 这5个Bench的结果：
＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆
C＃.net根本不值一提，0：5 输给java。
在综合比分上，java VS C#=324:240
java大比分领先
至于mono就差的更远了
java以324：163完胜mono再来个证据：Java is quite efficient nowadays, and it is often reported that it can outperform C++ under some circumstances because it can perform run-time optimizationsJava目前效率很高，经常有报告说Java性能高于C++，因为Java能进行运行时的优化
http://www-pw.physics.uiowa.edu/das2/das_qa.htmlSwing GUI图形界面的性能：
在菜单、树形、文本框、table等几项上，jdk1.4.0比jdk1.3.1快４０％到９０％Reflection的性能上，jdk1.4.0比jdk1.3.1快２０倍！快２０倍以上的还包括远程窗口调用其它各项上，jdk1.4.0几乎都比jdk1.3.1快５０％以上，“Java慢”也只是“历史”了
其它各方面的性能提升在此
http://java.sun.com/j2se/1.4/performance.guide.html
ＳＵＮ的数据说明，JDK1.4.2在各方面的性能是jdk1.4.1的５０％到３８０％
可以看到，几乎每次java的版本提高都带来性能的极大提升。所以如果你在某处看到一个bench说Ｃ＋＋比java快，那就很可能是用的老版本的java。
但是Ｃ＋＋近年似乎没什么速度的提升
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html
http://community.csdn.net/Expert/TopicView3.asp?id=3636713 (太长，要几分钟才能打开)请认为本贴有价值的人将本贴存在自己的电脑中（用ＩＥ可能无法直接存储，请用FireFox存储，或全选本文再存成txt文件）C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。
很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些两者有着本质的不同，但是有些Qpper用一辈子也无法理解这其中的差别，
他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生
以下是Java比Ｃ＋＋快的理论依据：
关于java如此快的原因：
有些东西确实只有JIT能做到：比如中提到：
http://www.idiom.com/~zilla/Computer/javaCbench.htmlThe compiler knows what processor it is running on, and can generate code specifically for that processor。
JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。在这一点上，C++的静态编译器肯定做不到。
# The compiler knows what processor it is running on, and can generate code specifically for that processor. It knows whether (for example) the processor is a PIII or P4, if SSE2 is present, and how big the caches are. A pre-compiler on the other hand has to target the least-common-denominator processor, at least in the case of commercial software.
JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。它知道是否处理器是P3或P4，是否SSE2存在，cache有多大。一个C++之类的预先编译器只能针对所有处理器的指令集的“最小公分母”进行编译，至少在商业软件中是这样的。
# Because the compiler knows which classes are actually loaded and being called, it knows which methods can be de-virtualized and inlined. (Reably, modern java compilers also know how to "uncompile" inlined calls in the case where an overriding method is loaded after the JIT compilation happens.)
因为JIT编译器知道哪些类被实际装载和调用，它知道哪些方法可以被“消虚拟化(de-virtualized)”
和内联(值得一提的是：当代java编译器还能知道在被覆盖的方法被装载的情况下，在JIT编译后进行“逆编译”内联的方法调用)
# A dynamic compiler may also get the branch prediction hints right more often than a static compiler.
动态编译器可以进行更多的分支预测
重点强调：
＊＊＊
Java速度如此快的原因在此（来源：IBM东京研究院）
http://www.is.titech.ac.jp/ppl2004/proceedings/ishizaki_slides.pdf
＊＊＊
其中有6大步优化，
每个大步中又有若干小步的优化，
共几十步的优化。
自己看吧，英语比较简单，只是内函比较难理解，
如果自己看不明白，别人解释也一样听不懂。
某些Qpper们认为：根本就不存在Java，只存在C++，Java只是一个C++的程序。
但他们却在有意回避一个事实：用C++编译器编译出来的本地代码才是C++程序
用Fortran编译器编译出来的本地代码才是Fortran程序
用Delphi编译器编译出来的本地代码才是Delphi程序
用C#编译器编译出来的本地代码才是C#程序
用VB.net编译器编译出来的本地代码才是VB.net程序
用Java编译器编译出来的本地代码才是Java程序如果照某些Qpper的观点，那么世界上只有机器语言一种语言，因为其它语言归根结底都是机器语言程序，岂不荒唐？
而Java的本地代码是用Java的JIT和HotSpot编译器在程序运行时编译出来的，根本不是C++编译器编译出来的，所以java程序根本不是一个Ｃ＋＋程序！
JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化，C++编译器可以吗？
JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化，C++编译器可以吗？
JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测，C++编译器可以吗？
大家可以去jre1.5.0的安装路径中去看看：
其中的jar文件共有５０.5Ｍ，由于jar文件是压缩文件，并且bytecode的代码要比native code精简的多(前面已经说过了：一个构造方法在bytecode中只要一个指令，构造方法在C++的编译器却要11个指令。Java 一個 method call 只要一個machine code，但用 x86 相對需要 4 個)，所以这５０.5Ｍ的java程序完成的工作大约相当于２００Ｍ以上的本地代码完成的工作。
而其中的.exe和.dll共有7.7M,本地代码在java运行环境中占的比例连５％都不到。而这仅有的５％的“C++编译器产生的本地代码”(比如AWT.dll)在java程序运行时还要被JIT和HotSpot编译器重新编译成新的指令序列(例如：符合SSE2的指令集的指令)，并根据运行时的profile 来内联到其它java编译器编译出来的native code中成为全新的NativeCode序列所以C++编译器编译出来java本地库的机器代码序列在java运行的时候根本看不到，这些机器代码也被Java的JIT和HotSpot编译器重新编译并更改执行序列，这些“C++编译器编译出来的机器代码”已经变成了“Java编译器编译出来的机器代码”。最终，在CPU中执行的所有机器语言序列全部是由Java编译器产生的，与C++编译器没有一点关系C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。
很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些两者有着本质的不同，但是有些Qpper用一辈子也无法理解这其中的差别，
他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生
节选：c++ 的 virtaul method calling：
不算 argument 4 個指令c 的一般 call：
不算 argument 2 個指令java 的 virtual call：
不算 argument 2 個指令.c++ 的 constructor：
11 個指令C++ destructor：
8 個指令java 的 constructor：
2 個指令由此可發現，對動態配置物件的操作而言，Java 一個 method call 只要一個
machine code，但用 x86 相對需要 4 個，這是 Java 在指令集層面直接支援所致。
Joakim Dahlstedt 的來頭可不小，是 JRockit VM 的主要設計者，現任 BEA System
裡頭 Java Runtime Group 的技術長，這篇文章並非老王賣瓜，相反的，Joakim 要
我們明瞭，評斷 Java VM "bench" (效能評比) 的方式需要調整，主要是基於以
下幾項：1.一般的 bench 比較僅僅是 micro-bench level，不能推廣到 system-
level。
2.軟體產業開發方式發生了很大的變化，大量使用 class library、framework、
Application server，乃至 Web services。援引舊的 bench 僅能針對其中
個別 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.htmlJava 最初的實作是透過直譯器 (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 白皮書已有詳盡的介紹。全文
http://dev.csdn.net/develop/article/54/54057.shtm
节选：c++ 的 virtaul method calling：
不算 argument 4 個指令c 的一般 call：
不算 argument 2 個指令java 的 virtual call：
不算 argument 2 個指令.c++ 的 constructor：
11 個指令C++ destructor：
8 個指令java 的 constructor：
2 個指令由此可發現，對動態配置物件的操作而言，Java 一個 method call 只要一個
machine code，但用 x86 相對需要 4 個，這是 Java 在指令集層面直接支援所致。
Joakim Dahlstedt 的來頭可不小，是 JRockit VM 的主要設計者，現任 BEA System
裡頭 Java Runtime Group 的技術長，這篇文章並非老王賣瓜，相反的，Joakim 要
我們明瞭，評斷 Java VM "bench" (效能評比) 的方式需要調整，主要是基於以
下幾項：1.一般的 bench 比較僅僅是 micro-bench level，不能推廣到 system-
level。
2.軟體產業開發方式發生了很大的變化，大量使用 class library、framework、
Application server，乃至 Web services。援引舊的 bench 僅能針對其中
個別 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.htmlJava 最初的實作是透過直譯器 (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 白皮書已有詳盡的介紹。全文
http://dev.csdn.net/develop/article/54/54057.shtm
http://pub.chinans-ls.com/~jx/java/chapter/appe.htm
IBM’s research JVM (参考[38] )has demonstrated that Java can
outperform C and FORTRAN compilers even for numerical calculations.IBM研究的JVM已经证明了Java即使在数学运算中性能也超过C和Fortran。（参考[38]：作者：S. M. José Moreira, Manish Gupta,
论文： "A Comparison of Three Approaches to
Language, Compiler, and Library Support for Multidimensional Arrays in
Java,"presented at Joint ACM Java Grande - ISCOPE 2001 Conference,
Stanford University, 2001.2001年ISCOPE大会，２００１年在斯坦福大学召开 ）
http://aspen.ucs.indiana.edu/gce/C536javacog/c536featuresOfCoG.pdf再一个证据：
题目：＜＜Is Java ready for computational science?＞＞
＜＜Java为科学计算做好准备了吗？＞＞出处：Computer Science Dept., University of Karlsruhe, Germany
德国Karlsruhe大学计算机科学系
http://www.ubka.uni-karlsruhe.de/vvv/1998/informatik/27/27.pdf.gz
IBM的Java编译器以３：２战胜Fortran 90
Fortran90:Java的结果（单位为秒）
20:14
40:30
440:444
1080:1089
11790:11690
输了的两项是以不到！％的差距输的
而赢了的三项中有两项是以３３％以上的差距获胜的
文章中的结论：Conclusion：
Java will become a major language for computational science.
Java将成为科学计算中的主要语言
结论：Java与Fortran一样快
Java Pro 2002-2003中文精华合集[第1辑]
《Java够快吗》
http://act.it.sohu.com/book/chapter.php?id=51&volume=1&chapter=9
http://act.it.sohu.com/book/serialize.php?id=51
参考文献
J.E. Moreira, et. al.,"The Ninja Project,"
Communications of the ACM, 44(10), 102, (2001).
＜＜ACM通讯＞＞
Z. Budimli, K. Kennedy, and J. Piper,
"The Cost of Being Object-Oriented: A Preliminary Study,"
＜＜科学计算＞＞
Scientific Computing, 7(2), 87, 1999.Zoran Budimli网站的: www.cs.rice.edu/~zoran