Deprecate -UseCompressedClassPointers?

[Astigeevich, 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?

I mean if an application wants to keep in use more than 5-6 million classes, the application should forget about JIT compilation and performance. CodeCache will become a bottleneck.
It is an interesting question, whether JVM would fail or not. IMO it would crash. I think some data structures would not accommodate such stress situation.
It is also interesting how many classes JVM can currently keep alive and have JIT compilation working.
 > It would just continuously throw out old methods from the code cache?

This depends on compilation requests rate. The process of flushing code cache depends on GC.
If the rate is not high, this will happen. If the rate is high, the compilation will stop.

In any case the performance of an application will be hurt a lot.


Thanks,
Evgeny

From: Thomas Stüfe <thomas.stuefe at gmail.com>
Date: Thursday 6 February 2025 at 13:46
To: "Astigeevich, Evgeny" <eastig at amazon.co.uk>
Cc: hotspot-dev <hotspot-dev at openjdk.org>, "Kennke, Roman" <rkennke at amazon.de>
Subject: RE: [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 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<mailto: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<mailto:hotspot-dev-retn at openjdk.org>> on behalf of Thomas Stüfe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Date: Tuesday 4 February 2025 at 11:52
To: hotspot-dev <hotspot-dev at openjdk.org<mailto:hotspot-dev at openjdk.org>>
Cc: "Kennke, Roman" <rkennke at amazon.de<mailto: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.




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/b806011e/attachment-0001.htm>