Workloads that use >> 100,000 classes

[Thomas Stüfe]

I may be naive, but the current ideas toward far-class implementation did
not seem that complex. You need changes in the layout builder - the Klass
slot would probably just be masked as an injected LONG value - and in all
code that evokes a Klass* from a narrow Klass. You need to find and fix
code that assumes that a narrow Klass ID can be formed from every Klass*.
But we need to do this for the
"move-abstract-and-interface-classes-out-of-classspace" idea anyway. You
need to think about CDS archive generation and fix Klass* pointers in
archived objects. What am I overlooking?

In any case, +COH as sole remaining code path is not around the corner yet;
we still have time to think this over.

Cheers, Thomas

On Wed, Jul 17, 2024 at 4:36 PM Kennke, Roman <rkennke at amazon.de> wrote:

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