第一部分  走进Java

第一章    Exact VM

        在JDK1.2时，曾在Solaris平台发布过一款名为Exact VM的虚拟机，具备：两级即时编译器、编译器与解释器混合工作模式。它使用准确式内存管理（Exact Memory Management 或者叫做 Non-Conservative/Accurate Memory Management）而闻名，换句话说，即虚拟机知道内存中某个位置的数据具体是什么类型。

        举个例子，如内存中有一个32位的整数123456，它到底是一个reference（引用类型）指向123456的内存地址，还是一个数值为123456的整数，该虚拟机都有能力分辨出来，这样才能在GC（垃圾收集）的时候准确判断该数据是否还可能被使用。

        虽然该虚拟机较Classic VM先进许多，但是在商业应用上只存在了很短的时间就被HotSpot VM所替代。

第二章    64位虚拟机

        在几年前，主流的CPU就开始支持64位架构了。Java虚拟机也是很早就推出支持64位系统的版本。但Java程序要在64位系虚拟机上运行需要付出较大的额外代价：

            一、内存问题——由于指针膨胀和各种数据类型对齐补白的原因，运行于64位系统上的Java应用需要消耗更多的内存，较32位系统额外增加10%~30%的内存消耗。

            二、多机构测试结果显示，64位虚拟机的运行速度在各个测试中几乎全面落后于32位虚拟机，约有15%的差距。

        但是在 Java EE 方面，企业级应用经常需要超过4GB的内存，所以对于64位虚拟机的需求是非常迫切的，那么企业如何改善呢？

        ——许多企业应用选择使用虚拟机群等方式继续在32位虚拟机中部署。

        Sun公司也注意到了该问题，在JDK 1.6 Update 14 之后，提供了普通对象指针压缩功能（-XX:+ UseCompressedOops , 这个参数不建议显式设置，建议维持默认由虚拟机的 Ergonomics 机制自动开启），执行代码的过程中，动态植入压缩指令以节省内存消耗，但是开启压缩指针会增加执行代码数量，因为所有在Java堆里的、指向Java堆内对象的指针都会被压缩，这些指针的访问就需要更多的代码才可以实现，而且并不只是读写字段才受影响，在实例方法调用、子类型检查等操作中也受影响，因为对象实例指向对象类型的引用也被压缩了。随着硬件的进一步发展，计算机终结会完全过渡到64位的时代，这是一件毫无疑问的事情，主流的虚拟机应用也终究会从32位发展至64位，而虚拟机对64位的支持也将进一步完善。

        未完待续…