《深入理解Java虚拟机》第三版读书笔记（四）

深入理解Java虚拟机（4）走进Java

1.4 Java虚拟机家族

1.4.1 虚拟机始祖：Sun Classtic/Exact VM

它死了，却活在了人们的心中。

它是世界上第一款商用Java虚拟机，它就是——Sun Classic虚拟机。

1996.1.23 JDK1.0诞生，而承载这个JDK1.0的虚拟机，就是大名鼎鼎的Classic VM。

那时的它，还很稚嫩，稚嫩到只能使用纯解释器的方式来执行，如果要使用即时编译器就必须进行外挂，但如果加了外挂，即时编译器就会完全接管虚拟机的执行系统，解释器就不干活了。

在JDK1.2及以前，用户用Classtic虚拟机执行java -version命令时，会看到类似如下的输出：

java -version
Classtic VM (build JDK-1.2.2-001, green threads, sunwjit)

其中的“sunwjit”（Sun Workshop JIT）就是Sun提供的外挂编译器，类似的外挂编译器还有Symantec JIT和shuJIT等。

由于解释器与编译器二者不可兼得，这就意味着：如果要用编译执行，那么编译器就需要逐字逐句进行编译，为降低响应时间，这些编译器根本不敢应用编译耗时较高的优化技术。

因此，这个阶段的虚拟机虽然使用即时编译器输出本地代码，但执行效率和传统的C/C++程序有很大差距。

而这，就是“Java语言很慢”的起源。

1.4.1 还未上任就被辞退：Exact VM

为解决Classtic VM的各种问题，在JDK1.2时，在Solaris平台上发布了一款Exact VM虚拟机，它的编译执行系统已具备有现代高性能虚拟机雏形，如：热点探测、两级即时编译器、编译器与解释器混合工作模式等。

Exact VM：一个短暂存在的为了解决Classic存在的，基本具备现代虚拟机的特性，编译器之间与解释器的混合工作模式，以及准确的内存管理而成名。

准确式内存管理：是指虚拟机可以知道内存中某个位置的数据具体的类型。

例如内存中有一个32bit的整数123456，虚拟机将有能力分辨出它究竟是指向123456的内存地址的引用类型，还是一个数值为123456的整数。

正因为使用了准确式内存管理，Exact VM可以抛弃掉以前Classic VM基于句柄（Handle）的对象查找方式，减少了每次定位对象的一次间接查找的开销，显著提升效率。

基于句柄的对象查找方式：主流的对象访问方式共有两种，一种是通过句柄访问对象，另一种是通过直接指针访问对象。

在HotSpot虚拟机中主要使用第二种方式进行对象访问。

关于对象访问方式将会在2.3.3节进一步阐述。

为什么可以抛弃基于句柄的对象查找方式：

原因是垃圾收集后对象可能会被更改内存地址。

如果地址为123456的对象移动到654321，在没有明确查明123456是否是引用类型的前提下，虚拟机便不能把所有“值”为123456的都改成654321，所以需要使用句柄来保证引用值的稳定。

Exact VM技术相对Classtic VM来说先进了许多，但是，由于HotSpot VM的崛起，Exact VM还未壮大，便已凋零……

总而言之，Classtic VM是JDK1.2之前的唯一一款虚拟机，在JDK1.2时也与HotSpot VM并存，在JDK1.3时还能苟延残喘作为备用选择，直到JDK1.4才销声匿迹。

而Exact VM就比较悲催，甚至还没来得及发布Windows和Linux平台下的商用版本就被遗忘在历史的尘埃之中了。

1.4.2 武林盟主：HotSpot VM

HotSpot VM是JDK中的默认Java虚拟机，也是目前适用范围最广的Java虚拟机。

• 不是亲生的：并非由Sun公司研发的，而是由一家名为“Longview Technologies”的小公司设计。

• 上错花轿嫁错郎：HotSpot VM最初并非是为Java语言而研发的，它来源于Strongtalk虚拟机。而这款虚拟机中的很大成分的技术又是来源于一款为支持Self语言实现的“达到C语言50%以上的执行效率”的目标而设计的Self虚拟机，最终甚至还能追溯到20世纪80年代中期开发的Berkeley Smalltalk上。

• 成了一家人，进了一家门：Sun公司注意到这款虚拟机在即时编译等多个方面有着优秀的理念和实际成果，但唯一遗憾的就是不是自己家研究的成果。于是，1997年收购了Longview Technologies公司，从而获得了HotSpot虚拟机。

HotSpot既继承了Sun之前两款商用虚拟机的优点（准确式内存管理），也有自身技术上的优势。

热点代码探测技术：HotSpot虚拟机的热点代码探测能力能通过执行计数器找出最具有编译价值的代码，然后通知即时编译器以方法为单位进行编译。

如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准即时编译和栈上替换编译（On-Stack-Replacement，OSR）行为。

通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无需等待本地代码输出才能执行程序，即时编译的时间压力也相对减少，这样有助于引入更复杂的代码优化技术，输出更高质量的本地代码。

事实上HotSpot和Exact虚拟机基本是同时期的产物，一开始的HotSpot就是基于准确式内存管理的，而Exact VM也有几乎一模一样的热点探测技术。

最后Sun公司内部争吵抉择了一番，最终选择了HotSpot。

得益于Sun/OracleJDK在Java应用中的统治地位，HotSpot理所当然成为全世界使用最广泛的虚拟机，是虚拟机家族中毫无争议的武林盟主。

1.4.3 小家碧玉：Mobile/Embedded VM

在Java ME中，也有一款虚拟机，相比于Java SE而言，Java ME的发展并不算成功，所以它所对应的虚拟机也相对比较低调。

Java ME对应的虚拟机名为CDC-HI（C Virtual Machine，CVM）和CLDC-HI（Monty VM）。

CDC/CLDC：Connected （Limit） Device Configuration。

这是一款在JSR-139及JSR-218规范中定义的Java API子集，这组规范希望能够在手机、电子书、PDA等移动设备上建立统一的Java编程接口。

Java ME最大的一块市场“智能手机”已被Android和IOS二分天下。

而在嵌入式设备上，Java ME Embedded又面临着自家Java SE Embedded（eJDK）的直接竞争和侵蚀。

这里写得并不够详细，更多内容可以直接看书，或者从网上查看相关资料……

1.4.4 天下第二：BEA JRockit/IBM J9 VM

BEA JRockit：BEA System公司生产的虚拟机JRockit。

IBM J9 VM：IBM公司生产的虚拟机IBM J9。

• JRockit

JRockit号称“世界上速度最快的Java虚拟机”，但事实上，前三名虚拟机性能交替上升。

BEA将JRockit发展成一款专门为服务器硬件和服务器应用场景高度优化的虚拟机，由于专注于服务端应用，它可以不太关注于程序启动速度，一次JRockit内部不包含解释器实现，全部代码靠即时编译器编译后执行。

除此之外，JRockit的垃圾收集器和Java Mission Control故障处理套件等部分的实现在当时的Java虚拟机中处于领先地位。

但随着BEA被Oracle收购，JRockit永远停留在了R28版本，这是JDK6版JRockit的代号。

• IBM J9

IBM J9虚拟机并不是IBM公司唯一的Java虚拟机，但目前它是最受宠的一个。

J9是它的一个代号，它有一个拗口的名称（一般没人叫）：IBM Technology for Java Virtual Machine。

IBM J9的市场定位与HotSpot比较接近（严格而言IBM J9的市场更广泛），它是一款在设计上全面考虑服务端、桌面应用、再到嵌入式的多用途虚拟机。

开发J9的目的是作为IBM公司各种Java产品的执行平台，在和IBM产品搭配以及在IBM AIX和z/OS这些平台上部署Java应用。

IBM J9到目前为止还活着，它的职责分离与模块化做得比武林盟主HotSpot要更好。

由J9虚拟机中抽象封装出来的核心组件库（包括垃圾收集器、即时编译器、诊断监控子系统等）就单独构成了IBM OMR项目，可以在其他语言平台如Ruby、Python中的快速组装成相应功能。

如果为学虚拟机而阅读源码，更加模块化的J9不失为最好的选择。

1.4.5 剩余的Java虚拟机家族明天再说。