Workloads that use >> 100,000 classes

[Kennke, Roman]

I don’t agree with this. Only because we have supported this in the past (not even on purpose, just because that’s what the address space gives us), doesn’t mean we need to support it forever, especially if nobody’s ever using it. If there are no users who ever need > 500,000 classes, then implementing and maintaining it means to maintain dead code. The opportunity cost there is high: it complicates all changes in the affected code, it complicates backports an possibly worst of all, it may stand in the way of future enhancements, either because nobody can see them in the complexity of that code, or nobody dares to touch it, etc.

Even if we *can* find legitimate uses of >500,000 classes, we must ask ourselves if the cost of supporting that outweighs the benefits. On the other side, we may find that we (or the user) can figure out much better ways of solving that problem, and that may be a better use of brain resources that supporting ‘infinite’ amount of classes forever.

That’s why I’m doing this survey.

Cheers,
Roman


> On Jul 17, 2024, at 2:41 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> I don't know any. But I wonder if it matters.
> 
> 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.
> 
> 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.
> 
> Cheers, Thomas
> 
> 
> 
> 
> On Wed, Jul 17, 2024 at 2:18 PM Kennke, Roman <rkennke at amazon.de> wrote:
> Hello all,
> 
> 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:
> 
> Lilliput as planned to upstream in JEP 450 (hopefully JDK24): 22 bits = 2^22 ~= 4,000,000 Klasses
> Lilliput2 (4-byte-headers): 19 bits = 2^19 ~= 500,000 Klasses
> 
> 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).
> 
> From what I remember people saying:
> - 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.
> - 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).
> - 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.
> 
> Are there any other use-cases that any of you know about that might blow the 500K limit?
> 
> Thanks & cheers,
> Roman
> 
> 
> 
> 
> Amazon Web Services Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597