JDK-8350457 : Implement JEP 519: Compact Object Headers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-02-20
  • Updated: 2025-06-27
  • Resolved: 2025-05-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b25Fixed
Related Reports
Blocks :  
JDK-8339114 - DaCapo xalan performance with -XX:+UseObjectMonitorTable
Blocks :  
JDK-8353588 - [REDO] DaCapo xalan performance with -XX:+UseObjectMonitorTable
CSR :  
JDK-8354070 - Support Compact Object Headers as product option
Duplicate :  
JDK-8015828 - Compact Object Headers
Relates :  
JDK-8350272 - Deprecate UseCompressedClassPointers for removal
Relates :  
JDK-8340453 - C2: Improve encoding of LoadNKlass for compact headers
Relates :  
JDK-8305895 - Implement JEP 450: Compact Object Headers (Experimental)
Relates :  
JDK-8341703 - Remove Klass::_prototype_header
Relates :  
JDK-8341553 - Remove UseCompactObjectHeaders extra CDS archives
Relates :  
JDK-8354672 - JEP 519: Compact Object Headers
Sub Tasks
JDK-8354168 :  
Release Note: UseCompactObjectHeaders is a product option - Resolved
JDK-8355319 :  
Update Manpage for Compact Object Headers (Production) - Resolved
JDK-8355513 :  
Performance evaluation for Compact Object Headers - Closed
JDK-8357881 :  
Release Note: Compact Object Headers CDS Archive Generation and jlink Instruction - Resolved
Description
The Compact Object Headers feature should be supported as a production feature, and the option should not require the experimental mode flags to turn it on.  This will enable us to more readily encourage customers to use this feature and report any performance improvements that they experience.

The feature was tested as-if it was a production feature when integrated and has had ongoing testing.

In order to make this a product option, we need to do a few things.

1. Report and confirm performance information on the latest version of the software.  Verify that this is acceptable and expected.

2. Resolution to linked issues.

3. CDS archives will continue to not be generated by default.  Users will be provided instructions on how to generate the CDS archives. See JDK-8341553. [Withdrawn this suggestion]

4. Enable more testing in earlier Oracle tiered testing.  This is currently tested in tiers 5, 8 and 10.

5. File a CSR to add the option as a Product option (?)
Comments
Changeset: 1e57648a Branch: master Author: Roman Kennke <rkennke@openjdk.org> Date: 2025-05-22 10:48:50 +0000 URL: https://git.openjdk.org/jdk/commit/1e57648abd569295f42dc19c00edfcc90c00b1d3
22-05-2025
For this RFE, we would like to have the CDS archives built by default. As an experimental option, it made sense not to but the archives should be available if this is a product option. diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js index aa4d846280e..8eb68d439c6 100644 --- a/make/conf/jib-profiles.js +++ b/make/conf/jib-profiles.js @@ -254,7 +254,6 @@ var getJibProfilesCommon = function (input, data) { configure_args: concat( "--with-exclude-translations=es,fr,it,ko,pt_BR,sv,ca,tr,cs,sk,ja_JP_A,ja_JP_HA,ja_JP_HI,ja_JP_I,zh_TW,zh_HK", "--disable-jvm-feature-shenandoahgc", - "--disable-cds-archive-coh", versionArgs(input, common)) }; I'll add image size info when these builds are done. Without the two COH archives: jdk-25_linux-aarch64_bin.tar.gz 193.1 MB jdk-25_linux-x64_bin.tar.gz 195.3 MB jdk-25_macos-aarch64_bin-unstapled.tar.gz 187.6 MB jdk-25_windows-x64_bin.zip 192.8 MB With the two COH archives: jdk-25_linux-aarch64_bin.tar.gz 201.3 MB jdk-25_linux-x64_bin.tar.gz 203.5 MB jdk-25_macos-aarch64_bin-unstapled.tar.gz 195.7 MB jdk-25_windows-x64_bin.zip 201.0 MB
30-04-2025
Linking the release note for creating the CDS archives for -XX:+UseCompactObjectHeaders since we don't provide them by default to the release note for the new product option. I don't know how to get the doc updated at https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html#advanced-runtime-options-for-java
09-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24522 Date: 2025-04-08 19:32:02 +0000
08-04-2025
1. Yes, we need a CSR to add this as a product option. https://wiki.openjdk.org/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process 2. Could you post a PR for this so we can run internal PIT testing on it next week. 3. I'll move the prototype header issue to non-blocking. We discussed this internally.
08-04-2025
Can we move forward with this, now? I believe performance is well-tested, the outstanding Xalan regression is under control. Where do we stand with extended functional testing? From my POV it is looking good, but I have no insights into Oracle. Do we need a CSR? If so, we should file it quick, according to Joe. I don't think moving the flag to non-experimental poses a compatibility issue, though, so I would avoid the red tape if possible. Please let me know. What else?
08-04-2025
[~stuefe] I didn't do any deeper analysis like at this point. Such improvements in those metrics sound great and together with the decreased amount of GC work would explain much (if not all) the overall performance improvements.
03-04-2025
[~sjohanss] That matches my observations. I also see a significant decrease in CPU metrics (cache misses, memory loads etc) - up to 25% less - in similar scenarios.
02-04-2025
When preparing my performance slides for JavaOne I did some additional SPECjbb 2015 runs using `-XX:+UseCompactObjectHeaders`. I’ve attached two images showing the relative improvements when using compact object headers in JDK 24. These results are with limited tuning, but I’m setting a fixed heap size of 16GB and enabling NUMA (also using numactl to limit the process to use 40 cores over 2 nodes). For this configuration the results look good for all the tested GCs. I also looked a bit closer at the GC behavior and the amount of GC work is significantly down. To analyze this I used the fixed injection rate mode of SPECjbb 2015 for 30 minutes, because the compliant run increases the load over time which makes looking at pause times and such less interesting. Below is a summary for the different GCs: *G1* When using Lilliput the number of GCs are down with about 15%, from 1390 to 1170. The average GC pause is not affected and this leads to a 15% decrease in total GC pause time, 91s down to 78s during the 30min run. The higher percentile pause times are also very similar so no real change there. The fact that we do fewer GCs really help lower the promotion rate to old, since the young collections are more spaced out more objects have time die young, and the objects that are promoted are smaller (due to Lilliput). During the 30 minute run with Lilliput G1 does not need to start a concurrent cycle and at the end of the run the old generation usage is roughly 2.3GB, with baseline the old generation grows to around 7.4GB in 15 minutes and at that point a concurrent cycle has been started and finished to allow mixed collections. To drill down a bit more into this I also did a 2 hour run with G1 to see if we eventually would get a concurrent cycle with Lilliput, and I guess we will, but 2 hours was not enough and at the end of that run we had about 5.2GB in the old generation. The 2 hour baseline run saw 11 concurrent cycles. *Parallel* Similar to G1, the number of GCs and the total time spent in GC pauses are down with about 15%. We do more GCs with Parallel compared to G1, due to a smaller young generation (no explicit configuration for this). The count is down from 3060 to 2605 and the total time is down from 188s to 165s. Neither baseline or Lilliput run into a Full GC during the 30 minute run, but Lilliput has almost 30% lower old generation usage at the end of the run. So again, a much lower promotion rate. Average pause time and higher percentiles are no different with or without Lilliput. *ZGC* ZGC also sees a clear reduction in GC work with Lilliput. Both the number of major and minor collections are down and the total time is down, but each GC is slightly longer: Minor count: 3465 → 3011 Minor time total: 1535s → 1439s Minor time average: 443ms → 477ms Major count: 421 → 387 Major time total: 1825s → 1760s Major time average: 4.33s → 4.55s Average heap usage after GC: 6.67GB → 6.61GB Haven’t analyzed the ZGC logs much more at this point.
02-04-2025
The UseObjectMonitorTable performance issue isn't technically a blocker to making this option a product option, but will be something we need to address to make UseCompactObjectHeaders as the default. Eric Caspole [~ecaspole] and I have been running our standard benchmarks on linux-aarch64 (Neoverse N1) and linux-x64 (not sure which). The benchmarks are the usual set of applications. We've been sifting through the results - comparing default vs. om-table vs. lilliput-with-cds. So far we have a lot of numbers, but for the most part om-table and lilliput-with-cds compare somewhat equally. The only outlier we've had is DaCapo sunflow (old not DaCapo23 version) is about 24% slower on linux-aarch64. Delta from default to lilliput-with-cds: DaCapo-sunflow-large linux-aarch64: -24.42% linux-x64: -1.83% macosx-aarch64: -5.07% windows-x64: -1.63% Apart from that, we have regressions from default vs. om-table as reported in bug report JDK-8339114 in Dacapo-xalan and Derby. The Lilliput improves Derby by about 6-8% over UseObjectMonitorTable. It's still around 5% slower with UseCompactObjectHeaders on than without. Our SPECjbb2005, 2015 numbers are better with Lilliput, from about 7-8% SPECjbb2005 to 13% SPECjbb2015 (around 3% with the tuned and ZGC runs). There are some small footprint benchmarks that are 1-5% worse, possibly due to more native allocation of the OM table. That needs to be investigated - maybe the table starts out too big. Please post some performance data that you see here. We want to have information that would help write the release note to encourage turning this on. Probably doesn't have to be a matrix of your numbers. Just some expected results for expected application types. We might also need a CSR.
11-03-2025
[~coleenp] the C2 improvement was partially addressed by [~rkennke] in JDK-8340453. After that RFE, it is not clear if there is a better modeling of class pointer loading in C2, as long as both compact and non-compact headers are supported.
21-02-2025
I will run our internal standard Oracle benchmarks with the option and report here. We need to add other benchmark results to this issue as comments, motivating taking this out of experimental mode. Thanks.
20-02-2025
Added two blocked-by issues. [~rcastanedalo] also has an improvement that he wanted to look at for the added C2 code and will file an issue.
20-02-2025