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

[Thomas Stüfe]

On Fri, Feb 23, 2024 at 8:25 AM Erik Osterlund <erik.osterlund at oracle.com>
wrote:

> Hi Thomas,
>
> The use of UseCompressedClassPointers used to be intertwined weirdly with
> UseCompressedOops due to historic reasons. I broke that connection because
> we wanted compressed class pointers in ZGC, even though we don’t use
> compressed oops.
>
> After that was cleaned up I tend to think of
> -XX:-UseCompressedClassPointers in my head as some kind of alias for
> -XX:+WasteMemory which you would configure purely because you want to waste
> memory just for the sake of it.
>
>
Ha, beautiful. But let's see if someone else complains. I'll also ping the
Jruby devs; they are the worst metaspace users I know.


> /Erik
>
> On 22 Feb 2024, at 15:35, 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20240223/c2c1ad1f/attachment.htm>