P4
We plan to remove `-UseCompressedClassPointers`, which will break 32-bit (arm32, zero32). We need to find a way to address that issue.
32-bit is on the way out, and there is agreement in at least part of the community [1] about that. However, as [~aph] remarked, this will be a larger change that likely needs its own JEP, with its own two-step process of deprecation and removal (similar to how we did it for x86).
The aim of this issue is to determine if there is a simple way to support +UCCP on 32-bit systems.
Initial thoughts:
Decoding/Encoding seems rather straightforward. We could declare the entire 32-bit address space the encoding range. We set the encoding base to zero, run with a zero-shift, and decoding then is a noop, behaving exactly like it would were we running with unscaled encoding on 64-bit.
Storage/class space: This is a bit trickier. We have two options:
1) We port the class space to 32-bit.
Pro: This may be a straightforward port.
Con: This changes memory layout and introduces a new, large, contiguous region. 32-bit systems, with their limited address space, suffer from fragmentation. There may be (a few? many?) installations in the field that could be unable to place the class space and therefore would get a native OOM on VM start. This is especially true for installations using custom launchers if the JVM, upon loading, is confronted with a pre-populated address space.
2) We don't need the class space. We could leave storage as it is today in 32-bit, where Klass structures live in normal metaspace regions - many disjunct smaller areas sprinkled all over the address space. After all, the encoding range covers the whole address space; no need for class space.
Pro: minimal changes in metaspace
Con: There may be many places in the JVM where we implicitly assume that +UseCompressedClassPointers means "class space exists". It may be an annoying hassle to fix and introduce yet another technical debt (since this distinction makes no sense outside 32-bit).
One must probe each variant and determine what works better.
Beyond encoding and storage, there may be other issues that I'm not aware of that need to be addressed.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009889.html
32-bit is on the way out, and there is agreement in at least part of the community [1] about that. However, as [~aph] remarked, this will be a larger change that likely needs its own JEP, with its own two-step process of deprecation and removal (similar to how we did it for x86).
The aim of this issue is to determine if there is a simple way to support +UCCP on 32-bit systems.
Initial thoughts:
Decoding/Encoding seems rather straightforward. We could declare the entire 32-bit address space the encoding range. We set the encoding base to zero, run with a zero-shift, and decoding then is a noop, behaving exactly like it would were we running with unscaled encoding on 64-bit.
Storage/class space: This is a bit trickier. We have two options:
1) We port the class space to 32-bit.
Pro: This may be a straightforward port.
Con: This changes memory layout and introduces a new, large, contiguous region. 32-bit systems, with their limited address space, suffer from fragmentation. There may be (a few? many?) installations in the field that could be unable to place the class space and therefore would get a native OOM on VM start. This is especially true for installations using custom launchers if the JVM, upon loading, is confronted with a pre-populated address space.
2) We don't need the class space. We could leave storage as it is today in 32-bit, where Klass structures live in normal metaspace regions - many disjunct smaller areas sprinkled all over the address space. After all, the encoding range covers the whole address space; no need for class space.
Pro: minimal changes in metaspace
Con: There may be many places in the JVM where we implicitly assume that +UseCompressedClassPointers means "class space exists". It may be an annoying hassle to fix and introduce yet another technical debt (since this distinction makes no sense outside 32-bit).
One must probe each variant and determine what works better.
Beyond encoding and storage, there may be other issues that I'm not aware of that need to be addressed.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009889.html
- links to
-
Review(master)
openjdk/jdk/26491