RFR: 8376125: Out of memory in the CDS archive error with lot of classes [v4]

[Thomas Stuefe]

On Wed, 4 Feb 2026 07:59:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I think we should keep this PR simple -- only introduce the shift encoding and limit max archive size to 3.5GB.
> 
> The next step, whether to change UseCompactObjectHeaders to allow a larger range should be done in a follow up, as there are many more interested parties that may have different opionons.

Thank you, @iklam 

@XueleiFan :
> I was wondering if it is OK to support 4GB+ archive when UseCompactObjectHeaders is false.

I have strong reservations about that, at least until we have fixed CDS:

The problem is that CDS loads *all* metadata into the Klass encoding range. That includes non-Klass metadata. That wastes a *huge* amount of space.

The ratio of non-Klass data to Klass data is usually extreme - e.g. in Spring petclinic, it's 7:1. So we waste a large amount of encoding space for things that don't need it. Likely 70% .. > 80%.

That is why you can only load 300000 classes when the nKlass encoding range should give you space for 4 .. 6 million classes, depending on Lilliput and on the median object granularity.

I opened https://bugs.openjdk.org/browse/JDK-8377222 to track that problem.

We could fit far more Klass structures into class space. And that would also have another advantage: it might let you store huge CDS archives and still use compact object headers. Even a future proposed Lilliput2 with a 32-bit object header (reduces number of loadable classes to 512000) may still be in reach for huge CDS archives. 

If CDS were to load only Klass structures into the encoding space, this would also open the door to certain performance enhancements I have in mind, since Klass structures are stored more densely and we wouldn't waste as many nKlass ID slots on non-Klass metadata.

So I think that would be the right way to go forward. If we have implemented that, and you still run out of Klass encoding range, we really should take a close look at what application needs more than 4..6 million classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29494#issuecomment-3851954840