<p dir="ltr">Thanks for the response Alex.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Thanks again Alex.</p>
<br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, May 13, 2025, 7:33 PM Alex Buckley <<a href="mailto:alex.buckley@oracle.com">alex.buckley@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5/13/2025 4:06 PM, David Alayachew wrote:<br>
> Silly question -- what happens if you use this feature, but end up with <br>
> more classes than can fit in the class' object header? I like to think <br>
> of myself as aware of my project's performance metrics, but the number <br>
> of classes loaded is not a detail I track.<br>
<br>
Not silly -- considered in the prior JEP -- see "Compressed class <br>
pointers encoding" in <a href="https://openjdk.org/jeps/450#Risks-and-Assumptions" rel="noreferrer noreferrer" target="_blank">https://openjdk.org/jeps/450#Risks-and-Assumptions</a><br>
<br>
The abstract JVM has no limit to the number of loaded classes (see JVMS <br>
4.11 for things that do have limits). Maybe Roman can say how much <br>
stress testing has been performed with the HotSpot implementation to <br>
discover the practical limit to the number.<br>
<br>
Alex<br>
</blockquote></div>