<div dir="ltr"><div>I don't know any. But I wonder if it matters.<br></div><div><br></div><div>To my mind, if we want to make +COH the ultimate goal and the only supported mode, we need a fallback for more than X classes. X is strictly speaking infinite, since today you can disable compressed class pointers and have infinite classes as well. If you want to blow > 50GB of Metaspace on > 4mio classes today, you can do this by disabling compressed class pointers. Disallowing that would be a regression compared to older Java versions. Granted, it would only hurt weird outlier cases, but still a regression.<br></div><div><br></div><div>But OTOH, as long as COH is optional, we can live with a reasonable limit, e.g. 500K. Since the fallback would be to just switch off COH. I don't think we need to support e.g. far classes as long as COH is optional.</div><br><div>Cheers, Thomas<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 17, 2024 at 2:18 PM Kennke, Roman <<a href="mailto:rkennke@amazon.de">rkennke@amazon.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
Do we have any knowledge about workloads that would blow addressable class-limits with Lilliput? My current plan, with the improved encoding as implemented by Thomas, but would be very similar with any sort of indirection-table, Klass-ID, looks like this:<br>
<br>
Lilliput as planned to upstream in JEP 450 (hopefully JDK24): 22 bits = 2^22 ~= 4,000,000 Klasses<br>
Lilliput2 (4-byte-headers): 19 bits = 2^19 ~= 500,000 Klasses<br>
<br>
While we are investigating further any solutions to extend those limits (e.g. the near-/far-Klasses discussion, which I very much enjoy), I am trying to find out any actual use-cases that might need as many classes. Realistically, this can only be any sort of class-generator, but I’d like to know more specific, and not rely on hear-say and possible myths. Workloads that I encountered in real world rarely seem to blow 10,000, I don’t think I’ve ever seen 100,000(s).<br>
<br>
>From what I remember people saying:<br>
- Lambdas. I’m not sure this is an actual problem. AFAICT, each Lambda will generate one class and one instance of that class. That’s a 1:1 relationship between written code and generated Lambdas. It doesn’t look like it could possibly be order(s) of magnitudes worse than ordinary classes.<br>
- JRuby: Generates one class per Ruby function. Depending on the workload, this could be 100,000s, I suppose. OTOH, if I understand correctly, those would not get instantiated, could thus be abstract (if we can get JRuby to generate them that way) and we could simply not allocate them in Class-Space to begin with (just like abstract classes and interfaces).<br>
- I have heard from one customer who is worried about hitting the limit. I don’t have much information from them, but sounded like current compressed class-pointer limit of ~3,000,000 is ok, but ~500,000 might not be. I don’t yet know what exactly they are doing and whether or not there’s other ways to solve the problem (maybe they never get instantiated either?). I will try to find out more ASAP.<br>
<br>
Are there any other use-cases that any of you know about that might blow the 500K limit?<br>
<br>
Thanks & cheers,<br>
Roman<br>
<br>
<br>
<br>
<br>
Amazon Web Services Development Center Germany GmbH<br>
Krausenstr. 38<br>
10117 Berlin<br>
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss<br>
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B<br>
Sitz: Berlin<br>
Ust-ID: DE 365 538 597<br>
</blockquote></div>