前言
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
来源 | 阿里云开发者
作者 | 毛亮
