Deprecate -UseCompressedClassPointers?

[Thomas Stüfe]

Hi Evgeny,

you mean that since the code cache is limited to 2g, it is very unlikely to
have that many classes since a significant part of those would not be JIT
compiled? But the JVM would not fail, or? It would just continuously throw
out old methods from the code cache? But our current assumption is that the
only cases that are doing this are generator scenarios that create many
classes, but that those never get hot enough.

But its still a good point.

Cheers, Thomas

On Thu, Feb 6, 2025 at 2:34 PM Astigeevich, Evgeny <eastig at amazon.co.uk>
wrote:

> > Why would we still need `-UseCompressedClassPointers`? Two reasons:
>
> > …
>
> > 2) To load more than ~5-6 million classes….
>
>
>
> CodeCache size limit is 2G for all platforms.
>
> If those classes methods get JIT compiled, it is unlikely generated code
> will fit into CodeCache.
>
>
>
> -Evgeny Astigeevich
>
>
>
> *From: *hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Thomas
> Stüfe <thomas.stuefe at gmail.com>
> *Date: *Tuesday 4 February 2025 at 11:52
> *To: *hotspot-dev <hotspot-dev at openjdk.org>
> *Cc: *"Kennke, Roman" <rkennke at amazon.de>
> *Subject: *[EXTERNAL] Deprecate -UseCompressedClassPointers?
>
>
>
> *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.
>
>
>
>
> Hi all,
>
> I would like to get rid of the `-UseCompressedClassPointers` case since it
> would cut down the number of configurations we need to support and test
> from three to two (`-UseCompressedClassPointers`,
> `+UseCompressedClassPointers`, `+UseCompactObjectHeaders`).
>
> This would leave us with the now default case,
> `+UseCompressedClassPointers`, as the sole supported CCP case, thereby
> removing the need for the switch, which we therefore should deprecate and
> eventually remove.
>
> Apart from significantly reducing code complexity and testing effort,
> `-UseCompressedClassPointers` does not seem to be tested that well,
> especially on 64-bit platforms. See e.g.
> https://github.com/openjdk/jdk/pull/23053, and Roman's suspicion is that
> there are many more.
>
> It increases memory usage by quite a bit ("Alias for -XX:WasteMemory" -
> Erik Österlund), and any historical connection to UseCompresseedOops have
> long been removed.
>
>
> Why would we still need `-UseCompressedClassPointers`? Two reasons:
>
> 1) To support 32-bit, where, atm, it is the only implemented mode. But I
> am confident that I can find some low-effort low-code way to "fake"
> compressed Klass* pointers, since after all the 32-bit address space could
> be seen as a 4GB class space. There is also the bigger question of the
> future of 32-bit - we discussed this at the FOSDEM OpenJDK workshop, with
> mixed results, but it seems likely that 32-bit will go away at some point,
> the only question is when.
>
> 2) To load more than ~5-6 million classes. Class space, when maxed out,
> allows for about 5-6 million classes, given a typical Klass size
> distribution. I think that number is ridiculous, though. If you load or
> generate that many classes, you are a likely very patient programmer with a
> leaky or misdesigned application (just consider for a moment that to fill
> 4GB class space to the brim with Klass instances, would would typically use
> up about 5-10 times as much in non-class metaspace. That is for metadata
> alone. I cannot see a sane application doing that.
>
> Is anyone using -UseCompressedClassPointers for any valid reason I am not
> aware of?
>
> If not, barring any objections, my plan is to deprecate
> UseCompressedClassPointers for JDK25, find an alternative for 32-bit
> platforms in JDK26, and remove the uncompressed case in JDK 26 or later.
>
>
>
> What do people think?
>
>
>
> Amazon Development Centre (London) Ltd.Registered in England and Wales
> with registration number 04543232 with its registered office at 1 Principal
> Place, Worship Street, London EC2A 2FA, United Kingdom.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20250206/2ef434d1/attachment-0001.htm>