JDK-8341553 : Remove UseCompactObjectHeaders extra CDS archives
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-10-04
  • Updated: 2025-04-09
  • Resolved: 2024-11-19
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 24
24 b25Fixed
Related Reports
Relates :  
JDK-8344821 - Test CheckDefaultArchiveFile.java fails if classes_coh.jsa is not present
Relates :  
JDK-8305895 - Implement JEP 450: Compact Object Headers (Experimental)
Relates :  
JDK-8344844 - ciReplay tests fail with -XX:+UseCompactObjectHeaders because CDS is disabled since JDK-8341553
Relates :  
JDK-8350457 - Support Compact Object Headers as product option
Sub Tasks
JDK-8341555 :  
Release Note: UseCompactObjectHeaders CDS Archives Creation - Resolved
Description
When JDK-8305895 is integrated, there will be two more CDS archives built by default as part of the build called classes_coh.jsa and classes_nocoops_coh.jsa.

These shared archives should be removed so that 30 million users do not download these extra bytes that they will not be using.

The OpenJDK default for building archives will be changed to not build these by default so that we are not testing code we're not shipping.  Other vendors are free to change the default for their testing and deployment. [~rkennke]

After changing the default we need to:

1. Fix the tests to not fail when -XX:+UseCompactObjectHeaders is on that assume that there's a default archive present.
2. Add to the release notes instructions how to build the CDS archives locally if using -XX:+UseCompactObjectHeaders.
3. Maybe add a warning that the CDS archive isn't present with -XX:+UseCompactObjectHeaders (tbd).

Most CDS tests don't require having a default archive and build a local archive as part of the testing so CDS testing will still be covered with -XX:+UseCompactObjectHeaders.  Experimentally we found that there's only around 6 tests that need to be adjusted with this change.
Comments
If I am looking at this correctly this change disabled building of the classes_coh.jsa file for Oracle builds, but the CDSConfig still sets the default_archive_path as classes_coh.jsa. That causes test CheckDefaultArchiveFile.java to fail. Filed JDK-8344821.
22-11-2024
Changeset: acdbf833 Branch: master Author: Calvin Cheung <ccheung@openjdk.org> Date: 2024-11-19 23:37:34 +0000 URL: https://git.openjdk.org/jdk/commit/acdbf83325296511e6d27cc696911d81f99b8063
19-11-2024
Update: The classes*coh.jsa archives will be generated by default. In case the user doesn't want to generate those archives, just specify the --disable-cds-archive-coh option in the build configure command. In the Oracle build configuration, those archives will not be generated by default.
19-11-2024
I am in two minds about this. On one hand, I think the default OpenJDK build should enable all available features, and then downstream vendors are free to disable some of them for any reason: support, compatibility, distribution sizes. This allows testing feature paths as the matter of course during normal OpenJDK development, and then allowing vendors not to care about any particular product part. So it would be nice to have a build system flag for vendors, but keep it on by default to test Lilliput paths more thoroughly. On another hand, +UCOH is experimental feature, so it is a little bit odd to ship the default CDS archives for it. It would have been less controversial if +UCOH was a product feature, enabled by default. Then the whole thing would likely be a no-op, as we would probably refrain from building -UCOH CDS archives. So it is also okay to disable UCOH CDS archives by default.
13-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22051 Date: 2024-11-12 23:27:27 +0000
12-11-2024
I think this enhancement is not to generate the compact object headers related CDS archives (classes_coh.jsa and classes_nocoops_coh.jsa) by default. If the user needs to generate them, the user will need to specify the --enable-cds-archive-coh=yes build configure option.
12-11-2024
So this is only about changing the default in the Oracle build configuration? In this case that's fine by me.
07-11-2024
I was about to repeat what I said in the description. For Oracle products, we don't want them turned on by default because of the extra size. We'll adjust testing to have them on locally but not in the default build. You're free to change the default configuration for your own purposes. Hopefully eventually we won't have the -coops version also.
07-11-2024
I introduced them. I did not like the solution when I did it, but did not find a better solution. What [~rkennke] writes is somewhat correct, though, in that the -Coops archives only exist for the sake of ZGC. So the precedence was made by Oracle. But obviously, this approach does not scale endlessly. This is as much a political as a technical decision. I will feel around in our team as to how feelings run.
05-11-2024
I disagree. We build archives for -coops even if most users don’t use them. Those are used when a user runs with -coops. That‘s the same situation as for +/-coh: even though most users would not use it, those who do use it would benefit from the archives.
05-10-2024