HotSpot GC 具体实现关键点概要
2016-05-05 10:12
537 查看
HotSpot GC 具体实现关键点概要
GC roots 枚举过程
枚举过程的困难点:
范围大: GC roots主要在全局性的引用(常量与静态变量)和执行上下文(如栈帧中的本地变量表)。现在程序仅仅就方法区而言就很大,程序整体体积更是不用说。如果要注意检查这些引用,如查看所有栈帧中的本地变量表,那么时间上肯定是无法接受的。必须在快照中进行:在枚举过程中,不能出现程序运行。因为这会导致GC roots不断变化,造成统计不准确的情况。
时间要求高:由于分析必须停止程序的运行,因此时间必须要短
准确式GC
HotSpot采用了准确式GC以提升GC roots的枚举速度。所谓准确式GC,就是让JVM知道内存中某位置数据的类型什么。比如当前内存位置中的数据究竟是一个整型变量还是一个引用类型。这样JVM可以很快确定所有引用类型的位置,从而更有针对性的进行GC roots枚举。OopMap
HotSpot是利用OopMap(Ordinary Object Pointer Map)来实现准确式GC的。当类加载完成后,HotSpot 就将对象内存布局之中什么偏移量上数值是一个什么样的类型的数据这些信息存放到 OopMap 中;在 HotSpot 的 JIT 编译过程中,同样会插入相关指令来标明哪些位置存放的是对象引用等,这样在 GC 发生时,HotSpot 就可以直接扫描 OopMap 来获取对象引用的存储位置,从而进行 GC Roots 枚举。安全点
程序并不能在任意地方都可以停下来进行GC,只有到达安全点时才能暂停。此外,在安全点中,HotSpot也会开始记录虚拟机的相关信息,如OopMap信息的录入。安全点的选择不能太少,否则GC等待时间太长;也不能太多,否则会增大运行负荷。其选择的原则为“是否具有让程序长时间执行的特征”,如方法调用,循环等等。具体安全点有下面几个:循环的末尾 (防止大循环的时候一直不进入safepoint,而其他线程在等待它进入safepoint)
方法返回前
调用方法的call之后
抛出异常的位置
安全点暂停线程运行的手段有两种:抢先式中断和主动式中断。
抢先式中断
不需要线程的执行代码主动配合,在GC发生时,首先把所有线程全部中断,如果发现有线程中断的地方不在安全点上,就恢复线程,让它跑到安全点上再暂停。不过现在的虚拟机几乎没有采用此算法的主动式中断
GC需要中断线程的时候,不直接对线程操作,仅仅简单地设置一个标志,各个线程执行时去主动轮询查询此标志,发现中断标志为真时就中断自己挂起。轮询标志的地方和安全点是重合的,另外再加上创建对象需要分配内存的地方。安全区域
产生原因安全点机制保证了程序执行时进入GC的问题。但是对于非执行态下,如线程Sleep或者Block下,由于此时程序(线程)无法响应JVM的中断请求,JVM也不太可能一直等待线程重新获取时间片,此时就需要安全区域了。
运行机理
在线程执行到Safe Region中的代码时,首先标识自己已经进入了Safe Region。当在这段时间里JVM要发起GC时,就不用管标识自己为Safe Region状态的线程了。当线程要离开Safe Region时,如果整个GC完成,那线程可继续执行,否则它必须等待直到收到可以安全离开Safe Region的信号为止。
相关文章推荐
- .NET垃圾回收器(GC)原理浅析
- 深入理解PHP原理之Session Gc的一个小概率Notice
- 浅析Java中的GC垃圾回收器的意义及与GC的交互
- 浅谈关于Java的GC垃圾回收器的一些基本概念
- Android垃圾回收机制及程序优化System.gc
- 从JVM的内存管理角度分析Java的GC垃圾回收机制
- Java中垃圾回收器GC对吞吐量的影响测试
- 全面解析Java中的GC与幽灵引用
- Java堆空间占满的gc日志实例
- 大话JMM
- java.lang.OutOfMemoryError: GC overhead limit exce
- java性能优化 –gc日志收集与分析
- java7中G1垃圾收集器使用和流程总结
- java 虚拟机--新生代与老年代GC
- Erlang并发机制 – 垃圾回收
- JVM gc
- 自制垃圾清理工具
- Hotspot Shield Launch
- JDK5.0中JVM堆模型、GC垃圾收集详细解析