JVM发展历程以及各大JVM介绍
这篇文章中主要我们是要讲述以下HotSpot VM的由来
SUN Classic VM的介绍:
早在1996年Java1.0版本的时候, Sun公司就发布了一款名为Sun Classic Vm的Java虚拟机, 他同时也是世界上第一款商用Java虚拟机, JDK1.4的时候完全被淘汰了
-
这款虚拟机内部只提供了解释器
- 所以这也是为什么早期的Java的效率比较低的原因, 但是现在Java在如此庞大的生态环境下已经是一步步的开发,提升, 现在Java程序的执行效率已经是可以和C/C++一较高下了
-
那么如今Java已经效率上可以和C/C++一较高下了, 是否以后就能取代掉C和C++?
- 答案是不行的, 这个世界上没有最好的语言, 至于最适合某项工作的语言 , 每一个语言都有自己的长处
-
Sun ClassIc VM中如果要使用JIT编译器, 就需要外挂, 但是一旦使用了JIT编译器之后, JIT就会接管虚拟机的执行系统, 解释器就不再工作, 也就是JIT编译器和解释器在Sun Classic VM上只能同时使用一个, 不能混合使用
- 如果只使用JIT编译器, 而不使用解释器, 那么程序的执行效率确实是提高了, 但是启动程序时的响应时间会增长, 并且由于JIT编译器编译之后的机器指令是放在方法区的, 所以占用内存也是一定的问题,JIT编译器编译后生成的机器指令的大小会是字节码文件的十倍大小左右, 还是比较占用空间的, 但是现在我们的JVM中的方法区已经可以使用本地内存了, 所以对于这一点空间其实影响也不是很大
- 一些服务器中安装的JVM是只有JIT的, 因为在服务器中我们需要的是程序的执行效率, 对程序启动速度则是不怎么看重了
- 现在HotSpot VM内置了Sun Classic Vm
Exact VM(准确式的虚拟机)
这里准确式指定是准确式的内存管理
为了解决Sun Classic VM虚拟机的一些问题, JDK1.2时Sun提供了此虚拟机
-
Exact Memory Management : 准确式的内存管理
准确式内存管理是指虚拟机可以知道内存中的某个位置的数据具体是什么类型. 比如内存中有一个32bit的整数123456, 虚拟机将有能力分辨出他到底是指向了一个123456的内存地址的引用类型, 还是就是一个数值为123456的整数.
准确分辨出哪些内存是引用类型, 这也是在垃圾收集时准确判断堆中的数据是否还可能被使用的前提, 由于使用了准确式的内存管理, Exact VM可以抛弃掉以前Sun Classic VM基于句柄(Handle)的对象查找方式(原因是垃圾收集之后对象可能会被移动位置, 如果地址为123456的对象要移动到654321, 在没有明确信息表明内存中哪些数据是引用类型数据的前提下, 那么虚拟机肯定是不敢把内存中所有为123456的值改成654321的, 所以要以前使用句柄来保持引用值的稳定), 现在这样每次定位对象都少了一次间接查找的开销, 显著的提升了性能
-
具备了现代高性能虚拟机的雏形
-
但是Exact VM只在Solaris平台短暂使用, 其他平台还是Classic VM, 最终很快又被新诞生的HotSpot VM替换
HotSpot VM:
HotSpot历史:
最初由一家名为"Long View Technologies"的小公司设计, 1997年被sun公司收购
- JDK1.3的时候,HotSpot VM成为默认虚拟机
- 目前HotSpot VM有绝对的市场地位
- 不管是现在仍然有人使用的JDK6, 或者是现在大多使用的JDK8, 默认的虚拟机都是HotSpot
- Sun/Oracle JDK和Open JDK的默认虚拟机都是HotSpot(也就是开源JDK和不开源JDK都是使用的HotSpot作为默认虚拟机)
- 从服务器, 桌面到移动端, 嵌入式都有应用
-
名称中的HotSpot指的就是它的热点代码探测技术
- 通过计数器找到最具编译价值的代码, 触发即时编译或者栈上替换(栈上替换: OSR)
- 我们目前只需要记住即使编译和栈上替换都是对热点代码进行处理的技术
- 通过编译器与解释器协同工作, 在最优化的程序响应时间与最佳执行性能中取得平衡
补充:
目前三大主要商用虚拟机:
- HotSpot
- JRockit
- 注意: 是JRockit而不是JRocket, 这里Rockit的意思是尽情摇摆的意思, 很多人都以为是Rocket(火箭)
- J9
HotSpot历史:
