RFR: 8377554: Load card table base and other values via AOTRuntimeConstants in AOT code [v5]

[Andrew Dinn]

On Wed, 25 Feb 2026 17:44:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov The macos aarch64 failure indicates a fake address in a ConP node. Real external address targets fit into 48 bits and the masm encoding and patching code rely on that. I think this is because we are seeing a ConP encoding a byte_map_base with a negative value -- the C2 barrier set assembler can pass such a ConP nodes into the library kit. That will not happen when we are generating AOT code but will happen otherwise.
>> 
>> I will modify the encoding for ConP to only apply the external reloc when we are dumping generating AOT code and see if that fixes the problem.
>
>>  I think this is because we are seeing a ConP encoding a byte_map_base with a negative value -- the C2 barrier set assembler can pass such a ConP nodes into the library kit.
> 
> Or any other external constant for which C2 use RAW address.  I am still puzzled why we do not see issues in premain without your special `lea()` code for external address.

@vnkozlov I think it is ready for retest.

I will try to reproduce this on macos so I can see what constants are causing the problem (my M2 box is running fedora so I'll need to switch over). I'm not clear that there is already a reloc at the point where the constant being used to feed a mov/lea. I'll run up gdb to check that on both linux and macos.

The latest patch only performs an lea with ExternalAddress for addresses which are above page zero and within 48 bits. That will ensure that real addresses like the ones passed in from libraryKit or the C2 barrier code are relocatable and will not mark fake addresses (including a negative byte_map_base that might get passed in when we are not dumping AOT code) as relocatable. That should be correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29884#issuecomment-3961154643