本篇文章是EngineYard公司官方博客在11月底更新的一篇文章，原文标题叫做《J is for JVM: Why the ‘J’ in JRuby?》（J是JVM，为什么JRuby要用J？）。EngineYard是一家以Ruby技术为核心的云计算服务供应商，而今年在吸纳了从Sun脱离的两位JRuby核心开发者之后，似乎开始计划将重心转移到JVM平台的JRuby上。本文由王玉磊编译，原译文标题为《深入分析：JVM的优点与缺点》。让我们看看JVM有什么好，吸引了这么多语言去投奔它。
当Java最初诞生的时候，它可以说是其他语言的进化版。不仅因为Java很简单，而且这一进化的语言还是一个可以运行第三方硬件字节码的虚拟机。它还是垃圾收集站，从而令存储管理和内核转储（core dump）不再是麻烦。当然还有它相当全面的类库。虽然它没有什么惊世的新性能，但它把许多语言的优点基于一身。
本来Java是一个简单独一的语言，但是Sun在长期运营Java的过程中出现了很多错误，比如将语言与runtime合用一个名字，从而使得用户在识别JVM语言项目如Jython、JRuby时难以从思想上隔离Java。最主要的是这样对runtime很不公，因为Java Virtual Machine (JVM)有很多自己的独特之处。
缺点
没有一种技术是完美的，JVM也不例外。如果你工作在一个没有Java语言配置的设备上，JVM便无用武之地。JVM为其他语言提供了基础，但JVM最初不是为这个理念设计的。比如我们作为分配对象来维护我们的堆栈时，通常我们会直接操作实时堆栈并添加我们维护所需的其他字段，除此之外再没有控制堆栈的更好的方法。
还有，当我们创建一个Ruby Fixnum时也很麻烦，我们把这些值用一个Java对象包装。Ruby的C implementation不过只是传递tagged ints，因为没有包装他们就不会符合各种列表，所以Java 基元（Java primitives）也不会切割它。
顺便说一下：JVM的启动时间也挺长。
那些为JVM编写高性能代码的开发者会觉得经常被JVM的black box特性所折磨，一旦你加载你的字节码，你就觉得像是摇动老虎机的游戏手柄一样忐忑，不知道结果如何，black box就是意味着不可知。
优点：
Hotspot
对于初学者来说，尽管Hotspot有些神秘，但是性能方面它确实很棒，因为动态建模（dynamic profiling）是优良性能的捷径。HotSpot从运行应用中采样数据，从而可以优化代码，进而得到良好性能。它相当于以模仿人工的方法进行优化。在程序运行的开始，Java代码仍然解释执行，但HotSpot引擎开始进行采样(Profiling)。HotSpot引擎可以集中精力来对HotSpot代码进行深度优化，从而使这部分代码的执行更加迅捷。因此当Hotspot优化时，它为优化设立了一层保护来确保优化的基本原理有效；但当这层保护失效时，优化就会很慢。
这里是Hotspot在使用中的一个演示：
在图表中我们运行了一个Mandelbrot Generator很多次，然后测绘它每次生成的时间。你会看到JRuby 1.4.0明显比Ruby 1.8.7以及1.9.2preview2表现更好。如果只看JRuby的起点，会发现比1.8.7慢，但当Hotspot运行后时间曲线迅速下降。
这里有个有趣的始建波动发生在循环6那里：实际上那是因为Hotspot的动态反优化启动。然后时间波动回到原来状态，优化结束。
Hotspot已经被全世界的开发者和拥趸支持了近十年，Java 4, 5, 6之间的提升让人印象深刻。每一次它的升级，性能都会有很多提升，它真是的是JVM的一大利器。
垃圾回收Garbage Collection (GC)
Java开发者花费大量时间来调试、测试、提高他们的VM，单是Garbage Collection的开发和维护就持续了15个年头，由此可见它的性能！而且JVM发布了多个垃圾回收器，所以这样一来即使加载的负荷超过了JVM中一个Garbage Collection，JVM也还可以允许你使用其他的Garbage Collection。因此，你可以自己调整任何你所使用的Garbage Collection，使之符合你的应用。
各种各样的回收站发挥着不同的作用。它们全部是压缩过的，所以不必担心存储的问题。它们都是增量型的（incremental）以缩短GC停滞的时间；它们还是分代的（generational），所以短时对象（short-lived object）回收得更快。有些是并行的，从而回收工作可以在多个核上分开运行；甚至还有同时发生的Garbage Collection，这样就没有了停滞时间。JRuby可以免费得到这些，现在的Java 7以及Java 6的u12，甚至还有一个新的G1回收站。
关于GC和JVM还有两个很巧妙的地方，从中可以获悉GC运行虚拟化和信息的情况。第一个是-J-verbose:gc flag，从中可以得到回收事件发生的时间、数量以及花费的时间，这可以让我们获悉垃圾回收器处理工作负载的好坏状况：
你可以记录这些事件并且计算出清理垃圾所需的总时间，还可以计算出你加载的工作负荷是否超过了回收器的能力，这可以帮助改变你的设计并通过调节堆栈大小来适配回收器。
第二个是通过jconsole查询JVM状况。Jconsole可以从许多角度查看系统，而且有一个很棒的memory tab来展示GC的运行状况，如下：
在右下角你可以看到绿色的框格，从中可以看到不同的生成占存储的多少。比如说你看到一个近乎满的survivor 生成，那意味着慢的满GC收集时刻，那么意思就是说这个应用可能不是很健全。
移植性
#T#无论是GC还是Hotspot都可以用在任何Java可用的地方。比方说，JRuby可以运行在其他平台上，Rails应用就可以运行在IBM主机上的JRuby上，而且这台IBM主机运行的是CP/CMS。
实际上，由于Java和OpenJDK项目的开源，我们正在看到越来越多的平台的衍生，因此JVM的移植性也将越来越棒。
成熟
JVM已有超过15年的历史，在过去的这些年里，许多开发者为它做出了许多贡献，使得它的性能一次又一次地提升，让JVM变得更加稳定、快速和广泛。
覆盖面
JRuby和JVM上的其他语言项目已经被开发者所承认，一个典型的例子是invokedynamic specification (aka JSR292)。JSR越来越配合新的语言，JVM已不再是Java一个人定制规则。JVM正在构建成为类如JRuby等项目的优良平台。
还有一个MLVM（multiple language VM）项目，好比是新特性的清算机构，是一个许多企业应用的开发者试图添加应用的地方，而这些应用正是他们想在JVM中看到的。而且JVM开发者互相协作、彼此影响，无疑这有利于JVM新特性的诞生。
这些细节都可以看到JVM正在关注开发者的需求，扩大他的覆盖面。
总之，JVM已经成为技术界越来越稳定的产品，Oracle/Sun的合并以及其他可能的商业闹剧都不会影响这一点。许多技术大鳄级公司（如Oracle、IBM、HP、SAP）已经为编写JVM的中间软件花了如此多的钱以至于在下个十年里他们可能不会再为JVM的发展做太大的贡献。
