Bug ID: JDK-8255840 AArch64: undefined behaviour in HotSpot cpu-specific code

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdResolved

Running AArch64 HotSpot with GCC undefined behaviour sanitizer reveals many cases of UB, including null pointer dereferences. In some cases we'll just have to live with it and be careful to test the VM, but in many cases the UB is pointless and can be made properly defined without significant loss of performance.
This is an umbrella bug report to capture them all; there will be several sub-reports.

This is no longer a problem: it's been fixed by several other patches.

19-07-2023

There are many cases. In particular, JDK-8276563 fixed a problem where instances of type Register exhibit UB in the form of wild pointer (including null pointer) dereferences. One day, I think this may bite us. Here's an example of what was happening: r0->encoding(); Where r0 is defined as (Register *)0. My patch for that bug changed things so that r0 is now defined as a pointer to the start of a static array of RegisterImpl. typedef const RegisterImpl* Register; extern RegisterImpl all_Registers[RegisterImpl::number_of_declared_registers + 1] ; inline constexpr Register RegisterImpl::first() { return all_Registers + 1; }; inline constexpr Register as_Register(int encoding) { return RegisterImpl::first() + encoding; } constexpr Register r0 = as_register(0); This is true on other ports as well, but I'm starting on AArch64.

26-05-2022

Please add a description. What code is referred to and in what way is the behavior undefined?

05-11-2020