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). A simple comment that "src is valid narrowKlass and a narrowKlass left-shifted is never larger than 4GB, so there can be no overflow here" could suffice. > @theRealAph: An alternative could be to remove movk mode altogether. Its > usefulness is really limited. > > The XOR mode we try first gives us more than enough possible mapping points > for the class space. And in the very rare case that does not work, we now > have the fallback mode. > > I think the movk mode is not used in practice at all. Only if we fall back to > whatever the OS gives us, and the OS just happens to give us a 32-bit aligned > address. I have a principle I try to follow: there should be no known dead code. This bug is itself evidence of why dead code is a Bad Thing. So either fix for this bug is fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32520#issuecomment-5461314284
