On Tue, 25 Aug 2026 12:30:10 GMT, Thomas Stuefe <[email protected]> wrote:
> Fixes a small bug in class space allocation on aarch64: > > We attempt to allocate for movk-compatible mode by allocating a base that is > 32-bit aligned and < 2ˆ48 (so, bits [32,48) are allowed). > > https://github.com/openjdk/jdk/blob/51bb52c5c0a5a764dd080dc23bed0829fd0ae638/src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp#L102-L104 > > However, the decoding then uses the right-shifted base before the movk. So > the base would have to be [32+shift, 48+shift) to work with that: > > https://github.com/openjdk/jdk/blob/51bb52c5c0a5a764dd080dc23bed0829fd0ae638/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L5612-L5620 > > With +COH, shift can be up to 10, whereas before COH it usually was 0. > > So the base we allocated may not actually be usable for movk mode. E.g. if we > allocated at 0x5'0000'0000, the right-shifted base would be 0x500'000, which > spills into the lower 32 bits reserved for the narrowKlass offset. > > [JDK-8387962](https://bugs.openjdk.org/browse/JDK-8387962) sort of handles > this now: before that patch, we would abort, but now we use the slightly less > optimal fallback decode mode. Still, it should be fixed, and that would also > simplify the decoding. > > --- > > Testing: tier1 on aarch64; gtests on aarch64. Note that the gtests are very > thorough and test decoding and encoding for all possible corner cases. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Windows test error unrelated. > Fixes a small bug in class space allocation on aarch64: > > We attempt to allocate for movk-compatible mode by allocating a base that is > 32-bit aligned and < 2ˆ48 (so, bits [32,48) are allowed). > > https://github.com/openjdk/jdk/blob/51bb52c5c0a5a764dd080dc23bed0829fd0ae638/src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp#L102-L104 > > However, the decoding then uses the right-shifted base before the movk. So > the base would have to be [32+shift, 48+shift) to work with that: > > https://github.com/openjdk/jdk/blob/51bb52c5c0a5a764dd080dc23bed0829fd0ae638/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L5612-L5620 > > With +COH, shift can be up to 10, whereas before COH it usually was 0. > > So the base we allocated may not actually be usable for movk mode. E.g. if we > allocated at 0x5'0000'0000, the right-shifted base would be 0x500'000, which > spills into the lower 32 bits reserved for the narrowKlass offset. > > [JDK-8387962](https://bugs.openjdk.org/browse/JDK-8387962) sort of handles > this now: before that patch, we would abort, but now we use the slightly less > optimal fallback decode mode. Still, it should be fixed, and that would also > simplify the decoding. > > Testing: tier1 on aarch64; gtests on aarch64. Note that the gtests are very > thorough and test decoding and encoding for a lot of corner cases. > > * [x] I confirm that I make this contribution in accordance with the > [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > > ### Progress > > * [x] Change must not contain extraneous whitespace > > * [x] Commit message must refer to an issue > > * [ ] Change must be properly reviewed (2 reviews required, with at > least 1 [Reviewer](https://openjdk.org/bylaws#reviewer), 1 > [Author](https://openjdk.org/bylaws#author)) > > > ### Issue > > * [JDK-8387962](https://bugs.openjdk.org/browse/JDK-8387962): Aarch64: > Bug in movk-compatible ccs allocation with +COH (**Bug** - P4) > > > ### Reviewing > Using `git` > > Using Skara CLI tools > > Using diff file src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547: > 5545: > 5546: case KlassDecodeMovk: > 5547: if (shift != 0) { Reviewer note: The ubfx before extracted bits [shift, shift+32), so it unnecessarily extracted (shift) bits from bit 32 and upward, even though the offset into the class space (the left-shifted narrowKlass) could never be larger than 4GB. I am not sure why it was done this way. Now, we just extract bits [shift, 32). E.g. for +COH and 22bit klass pointers and a max shift of 10, we would extract bits [10, 32). ------------- PR Comment: https://git.openjdk.org/jdk/pull/32520#issuecomment-5421321073 PR Comment: https://git.openjdk.org/jdk/pull/32520#issuecomment-5421324883 PR Review Comment: https://git.openjdk.org/jdk/pull/32520#discussion_r3853080349
