Deprecate -UseCompressedClassPointers?

[Thomas Stüfe]

Thanks, Evgeny, these are all good points.

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

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