性能文章>OopMap看不懂,怎么调优哇>

OopMap看不懂,怎么调优哇原创

2728532

哈喽,我是子牙。十余年技术生涯,一路披荆斩棘从技术小白到技术总监到JVM专家到创业。技术栈如汇编、C语言、C++、Windows内核、Linux内核。特别喜欢研究虚拟机底层实现,对JVM有深入研究。分享的文章偏硬核,很硬的那种。

 

手撸过JVM、内存池、垃圾回收算法、synchronized、线程池、NIO…

 

 

最近正在写三色标记算法,准备实现OopMap了,把JVM的OopMap机制认真梳理了下。为什么要梳理,而不是基于对理论的理解去写?为了尽量跟Hotspot源码保持一致。东西有点多,怕后面忘记,写几篇文章记录下。

 

国籍惯例,百度了下OopMap相关的文章,嗯,基本都是从周志明的书《深入理解Java虚拟机》摘录出来的,见怪不怪了。因为本人熟读Hotspot源码,所以本人的文章除了会把OopMap理论与GC、运行时串起来,还会加入我的独特理解,及Hotspot源码证明。

 

大概会讲这些:

1、垃圾收集器各个阶段与STW、安全点、OopMap之间的关系

2、识别数据类型的三种算法

3、GC如何找到JNI线程创建的对象

4、哪些场景会生成OopMap记录

5、生成OopMap记录的几个重要方法

6、OopMap记录如何理解

 

01

OopMap

 

一看到Oop,大家是不是条件反射:面向对象?面向对象map?好像说不通啊!

 

这里的Oop是普通对象指针的意思:ordinary object pointer。这里的map也不是指对应的数据结构是map,而是地图的意思。所以翻译过来就是普通对象指针地图,与现实很贴切。

 

何谓普通对象指针?就是指一个Java对象,在JVM中,或者Hotspot源码层面,对应一个C++实例。在Java层面,我们叫Java对象,在JVM层面,我们叫oop。

 

与之对应的就是klass,就是一个Java类在JVM中对应的C++实例。还有handle,这个是一整套机制,后面讲到GC处理JNI线程创建的对象时细讲。

 

oop-klass-handle机制,是JVM的基石,对于理解Hotspot源码,极其重要。

 

关于OopMap,很多人对它的基础理解都错了,自然看一些文章,怎么看都看不懂。

 

02

聊聊GC

 

语言学习最大的门槛是语言本身,比如C语言的指针。相对来说,高级语言如Java、Python、PHP等,语言本身难度较低,所以学起来比较容易。你觉得生活轻松,是因为有人替你承担了大多数,计算机的世界也一样。

 

高级语言学起来之所以轻松,是因为高级语言的运行环境,即虚拟机,为你承担了大多数。今天就谈谈其中之一的GC。

 

GC的目的很简单:自动回收内存。再精确点说,高效回收不被使用的对象占用的内存。为了这一目标,GC经历了串行回收到并行回收到并发回收阶段。

 

并发阶段好像已经是终点,于是开始在内存设计上做文章,经历了从一个大堆到1:1堆到1:1:8堆到region堆。好像基于region块的堆又是终点了。下一代GC将会是什么样呢?我也不知道,但我保持期待。

 

GC一般是找到还在使用的对象,打上标记,清理那些没有打标记的对象。那GC怎么找到还在使用的对象呢?分两个阶段:先找到活动对象,再基于活动对象引用链一层一层往下找。

 

活动对象在哪里:

1、Java线程栈中

2、JNI线程栈中

3、寄存器中

4、可能我没想到的情况

 

栈与寄存器都是无状态的,言外之意就是说GC时是不知道寄存器中或栈中那一串数字到底是oop还是就是数字。

 

 

那怎么办呢?JVM采用的是准确式GC,言外之意就是说能准确的知道哪些区域存储的是oop。怎么做到的呢?就是通过引入OopMap。其实就是一种空间换时间的方式,在GC来临之前,根据栈图及寄存器生成OopMap记录。

 

生成OopMap记录,必然带来额外的开销,所以不适合持续进行。就像一个商店盘点第二天需要进的货,不是卖出一件盘点一下,而是打烊前完整得盘点。程序世界也一样。那这个何时的时机是什么时候呢?就是GC之前,安全点激活,线程进入安全点的时候。

 

关于安全点,STW理解得不太好的小伙伴,可以看我另外一篇文章 传送门

 

下一个问题:GC是怎么基于根对象一层一层往下找的?言外之意是说GC是怎么知道对象哪些属性是引用?这就要说到另一个数据结构:OopMapBlock。这个本篇文章就不展开讲了,后面有机会会写文章单独讲,这里大家知道有这样一个东西的存在,做了这个事情,就可以了。学习,有的时候,需要囫囵吞枣。

 

总结一下,程序平时运行不会生成OopMap,只有在GC前才会生成OopMap。GC前会激活安全点,所有线程都会进入安全点,即STW。JVM根据平时运行形成的栈图创建OopMap记录,供GC时遍历根对象使用。这句话就是GC、STW、安全点、OopMap的完整关系。解释执行是这样运作的,编译执行还不太一样,后面讲。

 

这里有个新名词:栈图。栈图底层实现后面有空讲,大家只需要知道它是干这个事的就行:它用来标识局部变量表或操作数栈中每个slot存储的数据类型。

 

是不是有些小伙伴想到了记忆集及卡表?这里不展开讲,感兴趣的小伙伴可以看我之前写的一篇文章 传送门

 

03

准确式GC

 

前面一段好干有木有?来点不干的舒缓下情绪,因为后面还有更干的 ^_^

 

根据识别数据类型的准确度划分,有这三种算法

1、保守式GC:即不记录数据的类型,GC时全栈扫描,但是就算是全栈扫描,怎么区分是oop还是数字呢?进行边界比对,比如堆的起始位置是top,结束位置是bottom,在这中间的就是oop。很明显,这个算法实现起来很简单,但是太low了,效率也很低。

 

2、半保守式GC:根对象不记录类型,根对象派生出来的对象记录数据类型。比如根对象A的地址存储在栈中,没有标记类型,找出所有根对象需要全栈扫描,但是A对象的属性B对象,在类A的元信息中有记录,可以顺藤摸瓜找到,减少程序憨憨遍历时间。

 

3、准确式GC:不管是根对象,还是派生对象,都标记类型。JVM中引入外部数据结构OopMap+OopMapBlock实现了该算法。

 

采用准确式GC思路,本质就是说,程序平时运行多花费一点点时间记录数据,帮助GC时减少延时,是值得的。

 

到这里就把OopMap相关的理论知识讲完了。当然,Hotspot源码很庞大,关于OopMap机制的理解我也有可能犯错。对于文中的有些观点,如果你有不同的理解,欢迎找我交流,一起求真。

 

04

OopMap格式

 

经常看到的OopMap格式,大概有这些。我列出来,大家看看有木有自己见过的,下篇文章我展开讲。

 

 

 

 

你好,我是子牙。十余年技术生涯,一路披荆斩棘从小白到技术总监到大厂中间件到创业。技术栈如汇编、C语言、C++、Windows内核、Linux内核及特别喜欢研究虚拟机底层实现,对JVM有深入研究。分享的文章偏硬核,很硬的那种。不考虑交个朋友吗?关注硬核子牙

 

分类:标签:
请先登录,查看5条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得