Could we get rid of the UseCompressedClasses switch altogether, defaulting to const true?

[Kennke, Roman]

Hi Thomas,

I would be in favor of deprecating the flag asap - but keep the implementation around.

1. Because whoever shows up using millions of classes might want a workaround.
2. If we ever do the super-compressed class-pointers as laid out by John Rose here:
https://mail.openjdk.org/pipermail/lilliput-dev/2024-March/001405.html

We might still still need the implementation if we decide to use uncompressed class-pointers in the fallback-path.

I see no future for the CCP flag. When UseCompactObjectHeaders goes in, this could become an alias for CCP, for folks who need gazillions of classes, and with the super-compressed CP, we would be able to address ‘infinite’ amount of classes, but still use ~16 bits for it in the very common cases. Even UCOH is not meant to become permanent or even ever leaving the experimental status, but that is another discussion...

Roman

> On Mar 14, 2024, at 9:59 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> 
> To bottom line the discussion and the findings:
> 
> Removing UseCompressedClassPointers would limit us to 3GB Klass encoding range and ~5 million classes. These numbers are very high, so they only are of interest when generating classes. Generation also includes cases like Lambdaforms. 
> 
> Does that matter? There is no way to have a 100% answer here. My bet would be that these limits are high enough for all real scenarios and that most scenarios that run into these limits are probably pathological.
> 
> There is an unknown number of cases that may run with millions of classes but don't know it. These are cases that JDK <= 11 with heaps >32G. In these cases, CompressedClassPointers would silently default to false. If these cases upgrade their JDK, they will first be exposed to the UseCCP<->UseCoops decoupling, and if we hardwire UseCCP to true, have no ability to go back to having millions of classes. This, however, is a highly theoretical case. There may be no cases like this.
> 
> How should we continue? Should I move forward and open a CSR to start the deprecation process?
> 
> Thanks, Thomas
> 
> 
> On Wed, Feb 28, 2024 at 6:00 PM Roman Kennke <rkennke at gmail.com> wrote:
> Hi there,
> 
> I searched around in Amazon a little bit and all of the (very few) uses of -CCP all come from Apache Spark, which has this interesting code:
> 
> https://github.com/apache/spark/blob/ea2587f695cf34c8561c91ffc342b38995bdeb43/sql/core/src/test/scala/org/apache/spark/sql/execution/WholeStageCodegenSparkSubmitSuite.scala#L45
> 
> Looks like they are doing it to get a particular alignment of array elements.
> 
> This will be shaken up by my recent push of:
> https://bugs.openjdk.org/browse/JDK-8139457
> 
> Roman
> 
> 
> > On Feb 22, 2024, at 3:34 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> > 
> > Greetings,
> > 
> > Are there any realistic scenarios that would require UseCompressedClassPointers=false? Or could we make it constant at some point or remove the switch altogether?
> > 
> > The only reason I can see for UseCompressedClassPointers=off would be if the maximum class space size of 3GB is not enough. But how realistic is this really? Some numbers:
> > 
> > On average, a Klass is ~600-700 bytes. Therefore, 3GB of class space would be enough for ~5 million classes. Note that the typical size ratio of Klass-to-non-class-metadata is 1:6 .. 1:10, which means that 3 GB class space come with ~18..30 GB of non-class metaspace (see [1]). I think these are outlandish numbers. Do we need to support these scenarios? Some weird class generator scenarios maybe?
> > 
> > Other than class space max size not being enough, are there any reasons for -UseCompressedClassPointers?
> > 
> > Thank you,
> > 
> > Thomas
> > 
> > [1] https://github.com/tstuefe/metaspace-statistics/blob/master/Histogram.svg
> > 
> > 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879