JDK-8354672 : JEP 519: Compact Object Headers
  • Type: JEP
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Integrated
  • Resolution: Unresolved
  • Fix Versions: 25
  • Submitted: 2025-04-15
  • Updated: 2025-05-23
Related Reports
CSR :  
Relates :  
Relates :  
Description
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](https://openjdk.org/jeps/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][kennke].

  - In another setting, the number of garbage collections done by SPECjbb2015 is [reduced by 15%][johansson], with both the G1 and Parallel collectors.

  - A highly parallel JSON parser benchmark [runs in 10% less time][json].

It is time to change compact object headers from an experimental feature to a product feature.

[kennke]: https://github.com/rkennke/talks/blob/master/Lilliput-FOSDEM-2025.pdf
[johansson]: https://bugs.openjdk.org/browse/JDK-8350457?focusedId=14766358&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14766358
[json]: https://www.reddit.com/r/scala/comments/1jptiv3/xxusecompactobjectheaders_is_your_new_turbo/?rdt=40432


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](https://openjdk.org/jeps/450#Testing), in addition to the testing mentioned [above](#Motivation). 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](https://openjdk.org/jeps/450#Risks-and-Assumptions), future features may require additional object-header bits. We have already reserved four bits for [Project Valhalla](https://openjdk.org/projects/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](https://wiki.openjdk.org/display/lilliput).

Comments
[~rkennke] Can you remove the link "Anecdotally" in the last statement in "Performance" - it does not work and blocked.
29-04-2025

Good. You can submit now.
29-04-2025

Yes, thank you for that. I am asked mostly about bits in the header. May be add `Risks and Assumptions` section and say that COH currently reserves 4 bits in header and assumes that it will be enough for future JAva projects including Valhalla.
29-04-2025

Endorsement happens before propose to target. For submitting you need only my review.
29-04-2025

David also asked about leaving room for bits in the header for JEP 401: Value Classes and Objects (Preview)
29-04-2025

[~kvn] I am not totally sure about the JEP process, I believe you need to endorse the JEP (maybe in addition to reviewing?)
29-04-2025

And rename implementation RFE JDK-8350457 to "Implement Compact Object Headers (Production)"
29-04-2025

[~kvn] David asked to add the performance info to the JEP, I did so by adding a performance section at the bottom. Is that ok?
29-04-2025

Also link CSR to this JEP.
29-04-2025

After updating JEP I marked it as reviewed and you can submit it.
29-04-2025

[~rkennke] Please update JEP description as David suggested.
29-04-2025

[~rkennke] please incorporate that information into the JEP itself. Thanks.
17-04-2025

> - how COH has worked in with Project Valhalla in terms of the number of bits that need to be available COH currently reserves 4 header bits for Valhalla. The last time I have talked to a Valhalla engineer, I have been told it seems likely that they only need 3 bits. > - performance results We fixed one notable regression in JDK-8353588. Other than that, performance is at least neutral, often improved. See for example several reports here: https://bugs.openjdk.org/browse/JDK-8350457?focusedId=14766358&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14766358 This confirms what we found at Amazon, and what has been reported by 3rd parties, e.g. here: https://www.reddit.com/r/scala/comments/1jptiv3/xxusecompactobjectheaders_is_your_new_turbo/?rdt=40432
16-04-2025

[~rkennke] looking at the "Risk and Assumptions" for JEP 450 could you please provide information about the following: - how COH has worked in with Project Valhalla in terms of the number of bits that need to be available - performance results Thanks
15-04-2025