读《深入理解Java虚拟机》小记——第一部分

第一部分  走进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位的支持也将进一步完善。

        未完待续…

    原文作者:java虚拟机
    原文地址: https://blog.csdn.net/qq_35374224/article/details/80537418
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注