On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <[email protected]> wrote:
> _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to > push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed > Klass pointers remaining as the only option, the `UseCompressedClassPointers` > switch. > > For motivation, please take a look at CSR associated with the deprecation > (which we did for JDK 25) and the preparatory discussion we had at the start > of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its > goal is to remove most traces of the uncompressed Klass path and to take > advantage of opportunities for simplification. In some cases, I did not take > opportunities for further simplification to keep the patch somewhat legible; > it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation > left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. > This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run > with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. > The difference to (a, b) is that we don't use a class space. This was > implemented with JDK-8363998 [3] - for more details, please see that issue > and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected > metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an > interest in arm32 will have to step up and do their own, more thorough unit > testing. Also, I did not see anyone doing follow-up work after JDK-8363998 > [3] - so some issues may still lurk from that patch as well (but maybe > JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. > Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few > occurrences of old but benign bugs. Mostly old code assuming > CompressedClassPointers and CompressedOops were still tied together (example: > Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... These comments probably apply to many other locations: -------------------------------------------------------------------------------- But the changes should probably be done in a separate PR, if at all. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4919: > 4917: } else { > 4918: ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); > 4919: decode_klass_not_null(dst); The `decode_klass_not_null(dst)` call is now common to all branches, so it can be moved outside: if (UseCompactObjectHeaders) { load_narrow_klass_compact(dst, src); } else { ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); } decode_klass_not_null(dst); src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998: > 4996: ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes())); > 4997: ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes())); > 4998: cmpw(tmp1, tmp2); Same here, but with `cmpw(tmp1, tmp2)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3484591668 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543442496 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543444838
