New candidate JEP: 519: Compact Object Headers

[John Rose]

That estimate (4M classes) is a known **soft** limit.

There are many, many ways to raise that number!

This old thread has just a few:
https://mail.openjdk.org/pipermail/lilliput-dev/2024-June/001760.html

I also look forward to any reports on large numbers of
loaded classes.  I wonder if anyone’s actually studying that.

A jokey upper bound would be the number of classfiles in
some big slice through Maven.  It’s jokey because nobody
loads them all at once, of course, and there are also
class spun online.  Maybe someone can do better than that?
Maybe a maximal dependency graph among Maven jars?
(Mild nerd sniping here…)


On 13 May 2025, at 17:11, David Alayachew wrote:

> Thanks for the response Alex.
>
> Ok, that link was helpful. I can see now that there is definitely a 
> known
> limit, and the JEP preceding this one is aware of that limit and 
> designed
> around it. All I am missing now is what happens when we go past that 
> limit.
> Hopefully Roman can answer that.
>
> Thanks again Alex.
>
> On Tue, May 13, 2025, 7:33 PM Alex Buckley <alex.buckley at oracle.com> 
> wrote:
>
>> On 5/13/2025 4:06 PM, David Alayachew wrote:
>>> Silly question --
>>> what happens if you use this feature, but end up with
>>> more classes than can fit in the class' object header? I like to 
>>> think
>>> of myself as aware of my project's performance metrics, but the 
>>> number
>>> of classes loaded is not a detail I track.
>>
>> Not silly --
>> considered in the prior JEP --
>> see "Compressed class
>> pointers encoding" in 
>> https://openjdk.org/jeps/450#Risks-and-Assumptions
>>
>> The abstract JVM has no limit to the number of loaded classes (see 
>> JVMS
>> 4.11 for things that do have limits). Maybe Roman can say how much
>> stress testing has been performed with the HotSpot implementation to
>> discover the practical limit to the number.
>>
>> Alex
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20250513/159c1a03/attachment-0001.htm>