JEP 519: Compact Object Headers
| Owner | Roman Kennke |
| Type | Feature |
| Scope | Implementation |
| Status | Proposed to Target |
| Release | 25 |
| Component | hotspot / runtime |
| Discussion | hotspot dash dev at openjdk dot org |
| Effort | S |
| Duration | XS |
| Relates to | JEP 450: Compact Object Headers (Experimental) |
| Reviewed by | Coleen Phillimore, Stefan Karlsson, Vladimir Kozlov |
| Endorsed by | Vladimir Kozlov |
| Created | 2025/04/15 14:01 |
| Updated | 2025/05/14 13:11 |
| Issue | 8354672 |
Summary
Change compact object headers from an experimental feature to a product feature.
Non-Goals
It is not a goal to make compact object headers be the default object-header layout.
Motivation
Compact object headers were introduced as an alternative object-header layout by JEP 450 in JDK 24. Features of this size are best introduced carefully and gradually, so we introduced it as an experimental feature.
Since JDK 24, compact object headers have proven their stability and performance.
They have been tested at Oracle by running the full JDK test suite. They have also been tested at Amazon by hundreds of services in production, most of them using backports of the feature to JDK 21 and JDK 17.
Various experiments demonstrate that enabling compact object headers improves performance:
-
In one setting, the SPECjbb2015 benchmark uses 22% less heap space and 8% less CPU time.
-
In another setting, the number of garbage collections done by SPECjbb2015 is reduced by 15%, with both the G1 and Parallel collectors.
-
A highly parallel JSON parser benchmark runs in 10% less time.
It is time to change compact object headers from an experimental feature to a product feature.
Description
Compact object headers are enabled in JDK 24 via the command-line options
$ java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders ...The first option, -XX:+UnlockExperimentalVMOptions, will no longer be needed once they are a product feature.
Testing
Compact object headers were subjected to massive testing as part of JEP 450, in addition to the testing mentioned above. No further testing is required.
Some tests currently supply the -XX:+UnlockExperimentalVMOptions command-line option when enabling compact object headers. This will no longer be needed, so we will adjust these tests accordingly.
Risks and Assumptions
As discussed in JEP 450, future features may require additional object-header bits. We have already reserved four bits for Project Valhalla. If a need for even more bits arises then we can shrink compressed class pointers and identity hash codes even further, using techniques we have already prototyped in Project Lilliput.
