Permanent Generation Removal Overview（译文）

英文原稿：http://vdisk.weibo.com/s/vxGdGZEZTEjk

中文整理稿：http://it.deepinmind.com/gc/2014/05/14/metaspace-in-java-8.html

其实上面的整理稿，是针对这篇英文文稿的翻译兼整理，但是感觉有点乱，有点强迫症，所以干脆自己来翻译。关于vm相关性能数据的监控部分略掉了，此稿件主要是介绍perm gen的设计与移除，以及移除perm gen之后新的内存模型，所以后面关于内存的调优还有性能的监测都过于简单，如果想了解，可以去看周志明先生的《深入理解Java虚拟机》，里面对jstat等工具有更多的介绍。

翻译：

Oracle HotSpot JVM中的perm gen保存了HotSpot用于描述Java对象（Java objects）的元数据（metadata）。perm gen在Full GC中会和Java堆（Java Heap）一起经历垃圾回收。perm gen在JDK8中的HotSpot中，已经被移除了。本节简单的描述了perm gen及移除它的动机。还讨论了移除perm gen可能对Java程序的执行造成的多方面的影响。

议题

• 什么是perm gen
• 现在的元数据在哪儿
• 压缩的类指针
• 新的调节参数
• Memory Pool MXBeans

什么是perm gen

• 全名permanent generation
• 是Java Heap中用于存储虚拟机类的元数据的区域
• Java类在HotSpot中的内在表现
  • 类的结构信息，字段，名字
  • 方法的汇编信息和字节码
  • Vtables(虚函数表)
  • 常量池和符号解析

含有perm gen的vm内存分布示意图:

PermGen 大小

• 1.受限于参数MaxPermSize（默认是64M－85M）
• 2.需要Java Heap中连续的存储空间：如果分配的堆空间不连续，那么从old gen和perm gen定位指向新对象的引用，代价就会更大，而且也会更复杂。（card table   remembered set）
• 3.一旦耗尽，就会抛异常
  • 清除引用来触发类卸载
  • 配置更大的MaxPermSize
• 4.perm gen的大小依赖于类的数量，方法的大小，以及常量池的大小

为什么要移除PermGen

• 启动的时候就要指定大小，难以调优：MaxPermSize要设多大？
• HotpSpot内部类型是Java对象，可能会在Full GC中移动，对应用程序来说，不透明，并且非强类型，很难调试，需要用于存储元数据的空间
• 简化Full GC
  • 为每个收集器的元数据指定迭代器
• 希望能并发的回收类型数据空间，而不是在GC停顿期间
• 使受限于permgen的未来的改进成为可能

元数据去哪儿了？

得益于Java语言特性：类及相关元数据的生命周期和累加载器相匹配

每一个加载器的存储空间

• 仅线性分配
• 没有单独的回收（除非RedefineClasses和类加载失败）
• 没有GC扫描和整理
• 不需要重新安置元数据空间对象
• 当GC发现类加载器死亡，则整个空间一起回收

这些存储空间的集体称为Metaspace

Metaspace 分配

• 为元数据分配多个映射虚拟内存空间
• 为每个类加载器分配块状空间列表
  • 块的大小依赖于类加载器的大小
  • 为sun/reflect/DelegatingClassLoader, JSR292匿名类的加载器分配较小的块
• 归还内存块，以释放块状列表
• 当被清空的时候，归还虚拟内存空间
• 设计诸多策略来减少碎片

如下图：

（图中CL为类加载器，Boot CL为启动类加载器，vs1，vs2，vs3为虚拟内存空间，黄色的块为元数据块）

Java对象内存分配

堆上对象有指向Metaspace中自己类信息的指针—>_klass

在64位平台上，为了压缩JVM对象中的类指针，引入了“压缩类指针空间”（对象中的_klass变为4字节，指向压缩类空间中的数据，该数据再指向Metaspace中的类信息）

压缩指针（压缩类指针，压缩对象指针）

• 默认是为了64位平台
• 使用-XX:+UseCompressedOops 来压缩对象指针
  • oops是指普通对象指针
  • Java堆中对象的对象指针被压缩到32bit
  • 使用堆基地址（如果在低26G内存空间中，为0）即，指针的偏移量针对于堆的基地址
• 使用-XX:+UseCompressedClassPointers 压缩类指针
  • 对象的类指针（_klass）被压缩至32bit
  • 使用类指针压缩空间的基地址

Metaspace与类压缩空间的对比

• 类压缩空间只包含像接口指针（InstanceKlass），数组指针（ArrayKlass）等元数据
  • 仅当UseCompressedClassPointers为true的时候会这样
  • 为了性能问题，这里还保存了Java 虚方法表
  • 我们仍然在减少这个元数据类型
• 而Metaspace包含了元数据的其他所有的数据，这可能比较大，如方法，字节码，常量池

GC性能的提升

• 在Full GC，元数据到元数据的指针不需要扫描
  • 一大堆元数据扫描的复杂代码（尤其在CMS）都被删除了
• 元数据空间包含较少的指向Java Heap的指针
  • 指向java/lang/Class对象的指针存储在类元数据中
  • 数据类元数据中，有指向其成员类Class对象的指针
  • 我们要移除这些
• 元数据不再有整理消耗
• 减少了根扫描（不扫描VM已加载类的字典和其他内部的哈希表）
• Full GC的时间将会缩短（不同情况下可能会有所不同）
• 在G1中可以在并发标记之后进行类卸载
• 可以调优

调优标志

MaxMetaspaceSize

• -XX:MaxMetaspaceSize={unlimited}
• Metaspace受机器内存的限制
• 在虚拟内存切换频繁和本地内存分配失败之前，限制类元数据使用的内存

• • 如果类加载器内存可能泄漏
  • 如果在32位平台上，地址空间可能耗尽
• MaxMetaspaceSize是指Metaspace和压缩类指针空间的总和

MetaspaceSize

• 初始大小为21mb，超过这个值，将进行Full GC来回收类
  • GC的相关操作用于检测已死的类加载器，和未加载的类
• 如果在启动阶段发生了过多的GC，则需要设置一个高点的限制
• 可以使用与PermSize相同的值，来延缓初始GC
• 在下次Metaspace GC之前，High water mark会随着接下来合理数量的头空间的收集而增高

CompressedClassSpaceSize

• 当使用了-XX:+UseCompressedClassPointers 才有效
• -XX:CompressedClassSpaceSize=1G
• 因为这个空间只能在启动的时候设置，所以一开始就设置大一点
• 不使用的时候，不会分配
• 未来的工作，是要使这块空间可增长
  • 不需要连续，只需要从基地址可达
  • 更倾向于将更多的类元数据移到Metaspace中
• 未来可能会以性能为主导
  • PredictedLoadedClassCount （该标志目前处于试验性）：用于设置其他JVM内部数据结构的大小，像已加载类的字典
• 开发者可能会发现对于CompressedClassSpaceSize和UseCompressedClassPointers的不同命名。但在JDK-8015107中已经设定，对metaspace的概念，需要使用统一的命名方式

可以通过-XX:+PrintGCDetails and -XX:+PrintHeapAtGC来查看metaspace的使用情况

PermGen内存池以前在内存管理中属于Heap内存池的列表中，现在移除了

总结:

• HotSpot 元数据现在存在元空间中
  • 压缩类指针空间仍然需要被设定,但是要大一些
• 有调优标志,虽然并不是必须要使用的
• 这种改变使得其他优化与特性成为可能
  • 共享类数据
  • 新生代优化,G1进行类卸载
  • 元数据减少

译者有话说：

表示有些地方，我没看懂，不过总的还是有收获的。而且，我感觉是指导性文档，抠字眼就没必要了。最近一直在看JVM的相关内容，总结一句话，发展时间太久，各种词汇乱用，导致哪哪儿都模棱两可。

比如，现在从一些较官方的文档来看，Java Heap和我们常说的java堆是不同的，我们常说的java堆只包含新生代和老年代，是用来存储对象实例数据的，但是Java Heap是包括perm gen在内的GC作用的整个堆空间。有人说，这有神马影响吗？没影响的时候没影响，有影响的时候，真是搞脑子。

简单点概括

过去类的元数据存储在perm gen，作为Java Heap的一部分，使用instanceKlass，instanceKlassKlass，klassKlass（详见R大关于perm gen数据的追踪博客），接受GC传统意义上的扫描。弊端：内存受限，容易溢出；空间回收性能低等。现在的元数据存在元空间中。元空间由多个虚拟内存空间构成，每个虚拟内存空间又被划分为不同大小的块。以类加载器为源头，随着类的不断加载，不断从虚拟内存空间中分配块空间，从而使每个类加载器对应了一个块列表。当GC检测到某个类加载器已死，就整体释放整个列表，回收内存。

至于压缩类空间，出于多个原因考虑，主要有两个。第一，在64位平台，指针膨胀导致内存浪费，使用压缩类指针，压缩类指针空间基地址的概念，继续使用32位指针寻址；第二，这样一个空间还可以存储部分元数据，以提高相应性能。