前言

Java丰富的生态和语言强大的内存管理技术（GC），使得Java应用的开发非常便捷，各类应用场景的适配都非常优秀，大大减少了从Idea到应用落地的难度。不过这一切也不是没有代价的，针对于Java应用内存占用比较高的问题一直拿出来和其他语言比较。虽然JVM已经自带了例如指针压缩（compressed oops）来节约内存开销，不过Java Object对象头本身占用的内存还是非常可观。本文就介绍一下OpenJDK的最新技术，对象头压缩，来大幅优化Java对象的内存占用。目前这个技术尚未在Java语言官方实现OpenJDK中正式发布，但是Dragonwell11已经率先应用，请参考JDK发布指南：Dragonwell 11 release notes[1]。

Java对象头压缩 JEP 450: Compact Object Headers

Java对象头压缩技术，已经创建官方的JEP[2]。JEP源自Shenandoah GC的project lead Roman Kenne创建的Lilliput：https://openjdk.org/projects/lilliput[3]。（Lilliput意为《格列佛游记》中的小人国，含义不言而喻）

Java的对象布局

我们以基础类型java.lang.long为例

Compact object headers的核心逻辑是将单独的narrow klass指针（压缩class指针）encode在基础的对象头的第一个word：mark word中，释放原先单独占用一个word的narrow-klass/klass指针的空间，从而实现对Java对象头整体的压缩和内存占用优化。我们可以看到java.lang.Long对象应用对象头压缩后，内存占用从24 bytes减少到16 bytes，减少了1/3。由于原始layout的java对象头需要支持biased locking以及CMS GC，需要预留更多的unused bits，所以使用对象头压缩无法支持biased locking以及CMS。（注：biased locking在JDK17中默认关闭，JDK21+中删除，CMS GC在JDK17+中删除）

“Early adopters of Project Lilliput who have tried it with real-world applications confirm that live data is typically reduced by 10%–20%.”

JEP中提到，早期的项目试用者在实际应用中发现内存占用下降10-20%。

JEP 450: Compact Object Headers依赖的主要实现

JDK-8291555[4]

使用了一个stack locking的替换方案，代替了原先的stack locking。原先的stack locking需要将object mark word交换到stack上，而产生remote object header的情况，压缩对象头后，频繁lock/unlock会无法稳定获取klass指针。

JDK-8305896[5]

在G1等的Full GC中，object mark word会用来保存forward oop，从而在GC过程中，将无法正确获取class指针，因此，需要有额外的机制来保存forward oop。

JDK-8305898[6]

在G1/Parallel GC等的gc过程中，如果出现evacuation failure，将产生self forwarding的情况，对象头会用来存放自身对象指针（oop），也会引起class指针无法读取，因此需要换一种方法，使用self forward bit来标注java对象（oop）在gc过程中是否self forwarding。

JDK-8305895[7]

JEP450主体实现。完成了由+/-UseCompactObjectHeaders控制的对象头压缩的实现。

JDK-8328138（阿里巴巴Propose）[8]

修复了因为对象头压缩引起的ARM服务器Arrays.equals的潜在crash问题，并提升ARM服务器 Arrays.equals的性能。

UseCompactObjectHeaders实测效果

Dragonwell JDK的UseCompactObjectHeaders，进行了完善JDK回归测试，并在多个主流核心场景中进行了验证，主要有如下几个典型的优势：

1. Java对象内存占用减少5-10%左右

2. Java新分配对象内存占用（allocation rate）和GC频率降低5-10%左右

3. CPU和基础吞吐性能基本保持一致，部分内存带宽使用较高的场景中，显著提升吞吐性能(例如SPECjbb2015和Flink)

SPECjbb2015

在SPECjbb2015基准测试中（倚天平台），max（极限吞吐）和critical（低延迟要求吞吐）分别提升6.17%和9.01%。

Flink大数据

Flink的基准benchmark nexmark在倚天平台下，平均吞吐提升约10%。阿里云的客户实测得到近似的优化效果。

淘宝天猫电商核心应用

淘宝天猫电商核心系统，实测G1 young GC频率降低约7%。

对象头压缩Compact Object Headers FAQ

1. 如何使用对象头压缩功能？

在支持该功能的Dragonwell 11的JDK版本中，增加启动参数-XX:+UseCompactObjectHeaders，仅支持-XX:+UseG1GC(默认)和-XX:+UseParallelGC

2.为何OpenJDK官方未发布的技术，已经在Dragonwell 11中发布，使用会有什么潜在风险吗？

目前的Compact object headers的实现无法支持ZGC，ZGC支持依赖的JDK-8315884的实现尚未完成。同时Lilliput在Object header上的改动关系到Java未来重点项目Valhala project（Value Object）对Object header的定义，还没有明确定论。因此OpenJDK Compact object headers的正式发布还没有确切时间表，并非受制于本身技术实现。不过这并不影响我们在当前的JDK LTS版本中落地该技术，Dragonwell 11在支持Compact object headers时，仅支持最常用的默认G1 GC以及Parallel GC。目前在阿里内部各类场景中大规模使用，均未发现风险。

参考链接：

[1]https://github.com/dragonwell-project/dragonwell11/wiki/阿里巴巴Dragonwell11-Extended发布说明[2]https://openjdk.org/jeps/450
[3]https://openjdk.org/projects/lilliput[4]https://bugs.openjdk.org/browse/JDK-8291555[5]https://bugs.openjdk.org/browse/JDK-8305896[6]https://bugs.openjdk.org/browse/JDK-8305898[7]https://bugs.openjdk.org/browse/JDK-8305895

[8]https://bugs.openjdk.org/browse/JDK-8328138

来源｜阿里云开发者公众号

作者｜毛亮