RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5]
Thomas Stuefe
stuefe at openjdk.org
Thu Jul 31 07:02:10 UTC 2025
> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>
> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers.
>
> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>
> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>
> -------
>
> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>
> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>
> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>
> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design...
Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
- Fix some jtreg tests on arm
- fix arm gtests
- fix CompressedKlass* gtests on arm
- Merge master
- get rid of NEEDS_CLASS_SPACE define
- Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
- Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
- since to because
Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
- Remove stray include
- Update src/hotspot/share/oops/compressedKlass.cpp
Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
- ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f
-------------
Changes: https://git.openjdk.org/jdk/pull/26491/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=04
Stats: 196 lines in 17 files changed: 123 ins; 45 del; 28 mod
Patch: https://git.openjdk.org/jdk/pull/26491.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/26491/head:pull/26491
PR: https://git.openjdk.org/jdk/pull/26491
More information about the hotspot-dev
mailing list