OopMapBlock是一个简单的内嵌在Klass里面的数据结构,用来描述oop中包含的引用类型属性,即该oop所引用的其他oop在oop中的内存分布,然后就可以根据当前oop的地址找到所有引用的其他oop了,其定义如下:
源代码位置:oops/instanceKlass.hpp// ValueObjs embedded in klass. Describes where oops are located in instances of// this klass.class OopMapBlock VALUE_OBJ_CLASS_SPEC { public: // Byte offset of the first oop mapped by this block. int offset() const { return _offset; } void set_offset(int offset) { _offset = offset; } // Number of oops in this block. uint count() const { return _count; } void set_count(uint count) { _count = count; } // sizeof(OopMapBlock) in HeapWords. static const int size_in_words() { return align_size_up(int(sizeof(OopMapBlock)), HeapWordSize) >> LogHeapWordSize; } private: int _offset; uint _count;};
OopMapBlock结构可以描述某个对象中引用区域的起始偏移和引用个数。offset描述第一个所引用的oop相对于当前oop地址的偏移量,count表示包含的oop的个数,注意这里的包含并不是指这些oop位于OopMapBlock里面,而是有count个连续存放的oop。为啥会有多个OopMapBlock了?因为每个OopMapBlock只能描述当前子类中包含的引用类型属性,父类的引用类型属性由单独的OopMapBlock描述。
之前介绍过,可以利用-XX:+PrintFieldLayout来查看布局情况。该选项只在调试版本中有效。至于布局模式,可以使用-XX:+FieldsAllocationStyle=mode来指定,默认是1。之前介绍过布局模式有3种,如下:
allocation_style=0,字段排列顺序为oops、longs/doubles、ints、shorts/chars、bytes,最后是填充字段,以满足对齐要求;
allocation_style=1,字段排列顺序为longs/doubles、ints、shorts/chars、bytes、oops,最后是填充字段,以满足对齐要求;
allocation_style=2,JVM在布局时会尽量使父类oops和子类oops挨在一起。
当allocation_style的值为2时,父子oop的布局会连续在一起,这样至少有2个好处:
减少OopMapBlock的数量。由于GC收集时要扫描存活的对象,所以必须知道对象中引用的内存位置。原始类型不需要扫描。
连续的对象区域使得缓存行的使用效率更高。试想如果父对象和子对象的对象引用区域不连续,而中间插入了原始类型字段的话,那么在做GC对象扫描时,很可能需要跨缓存行读取才能完成扫描。
下面我们用HSDB来实际探查下相关的内存布局:
package jvmTest; import java.lang.management.ManagementFactory;import java.lang.management.RuntimeMXBean; class Base{ private int a=1; private String s="abc"; private Integer a2=12; private int a3=22;} class A extends Base { private int b=3; private String s2="def"; private int b2=33; private Base a=new Base();} class B extends A{ private String s3="ghk"; private Integer c=4; private int c2=44;} public class jvmTest { public static void main(String[] args) { Base a=new Base(); A a2=new A(); B b=new B(); while (true){ try { System.out.println(getProcessID()); Thread.sleep(600*1000); } catch (Exception e) { } } } public static final int getProcessID() { RuntimeMXBean runtimeMXBean = ManagementFactory.getRuntimeMXBean(); System.out.println(runtimeMXBean.getName()); return Integer.valueOf(runtimeMXBean.getName().split("@")[0]).intValue(); }}
运行main方法后,用HSDB查看main线程的线程栈,从中找出变量a,a2,b对应的oop的地址,如下:
分别查看0x00000000d69d98a0,0x00000000d69db5f8,0x00000000d69dd070对应的oop,如下:
上从面的截图可知,子类会完整的保留父类的属性,从而方便调用父类方法时能够正确的使用父类的属性。上述对oop的属性打印是按照类声明属性的顺序来的,内存中是这样保存的么?可以通过查看属性的偏移量来判断。
在Class Browser中搜索jvmTest,可以查找到我们三个自定义类对应的Klass,如下图:
分别点击这三个类查看属性的偏移量,如下:
根据上述偏移量,我们可以得出jvmTest.B对象的内存布局,如下:
int本身占4个字节,引用类型属性本质上就是一个指针,这里因为默认开启了指针压缩,所以也是4字节。
我们再看下表示OopMapBlock在Klass中的字宽数的属性_nonstatic_oop_map_size在三个类中的取值,如下:
OopMapBlock本身就只有两个int属性,所以一个OopMapBlock实例只有8字节,即一个字宽,jvmTest.B的_nonstatic_oop_map_size属性值为3,即由3个OopMapBlock,下面通过CHSDB的mem命令来看看这3个OopMapBlock对应的内存数据。
首先执行inspect对象得到该Klass本身的大小,即sizeof的大小,如下:
vtable,itable,OopMapBlock这三个都是内嵌在Klass里面的,所谓的内嵌实际是指这块内存是紧挨着Klass自身的属性对应的内存的下面,从上一节的分析可知,OopMapBlock在itable的后面,itable在vtable的后面,而vtable是紧挨着Klass的,从上述inspect命令的输出,也可知道itable和vtable的内存大小,单位是字宽,如下:
因此OopMapBlock的起始地址就是Klass的地址加上Klass本身的大小440字节即55字宽,再加上vtable的5字宽,itable的2字宽,总共加62字宽,OopMapBlock本身占用3个字宽,因此用mem查看这65字宽的数据,如下:
最后的3个字宽如下:
每个字宽对应一个OopMapBlock,前面4字节就是count属性,这里都是2,后面4字节就是offset,分别是20,36,48,与jvmTest.B的内存结构是完全一致的。
作者持续维护的个人博客http://classloading.com/。
相关文章的链接如下:
1、在Ubuntu 16.04上编译OpenJDK8的源代码
2、调试HotSpot源代码
3、HotSpot项目结构
4、HotSpot的启动过程
5、HotSpot二分模型(1)
6、HotSpot的类模型(2)
7、HotSpot的类模型(3)
8、HotSpot的类模型(4)
9、HotSpot的类模型(5)
10、HotSpot的对象模型(6)
11、操作句柄Handle(7)
12、释放句柄Handle(8)
13、类加载器
14、类的双亲委派机制
15、核心类的預装载
16、Java主类的装载
17、触发类的装载
18、文件流
19、解析Class文件
20、常量池解析(1)
21、常量池解析(2)
22、字段解析(1)
23、字段解析(2)
24、字段解析之伪共享(3)