Workloads that use >> 100,000 classes

[Thomas Stüfe]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/lilliput-dev/attachments/20240717/fd85066c/attachment-0001.htm>