RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to preuniverse stubs

[Vladimir Kozlov]

On Wed, 23 Jul 2025 13:19:35 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> @TheRealMDoerr @offamitkumar @RealFYang please test these changes on your platforms.
>
> @vnkozlov I'll note straight off that the situation here is complicated by the fact that `crc_table_adr` and `crc32c_table_addr` are pseudo-'entries'. They do not actually hold (code or data) addresses in generated code. What they really identify is an arch-specific address for foreign (C++) data that is assigned as a side-effect of performing generation for other entries. the only reason for marking them as entries is so we get a generated field and associated getter in class `StubRoutines`.
> 
> I'm not sure we need to care too much about their pseudo-entry status. More importantly, I dislike your solution of moving the initialization into `generate_preuniverse_stubs()`. This moves that initialization step away from the generator code that uses the resulting value, making it harder to see how the intrinsic works. It also has the unfortunate side effect of forcing us to create a preuinverse blob for every arch even if when we don't really need one.
> 
> You are right that we cannot add these addresses to the external addresses list under `AOTCodeCache::init2()` (via the call to `table->init_extrs()`) because the assignment of the pseudo-entry has not yet happened. However, we have two alternatives.
> 
> 1) We can simply pretend that they are real entries add them to the stub addresses list under `AOTCodeCache::init_early_stubs_table()` (via the call to `table->init_early_stubs()`). That will successfully advertise them  after they have been created as addresses that need relocation at AOT Cache load. However, it will also misclassify them as addresses in generated code when they are actually foreign addresses. Do we care about that misclassification (do we use a different reloc for stubs addresses vs external addresses?)
> 
> 2) We can leave the external addresses table open at the end of the call to table->init_extrs()`. When we enter table->init_early_stubs() we can add these two extra 'pseudo-stub' addresses to the external addresses list and close it before registering the early stubs addresses.
> 
> Both of these seem to me to be simpler and cleaner ways to deal with the address publication problem. What do you think?

Thank you, @adinn  for you suggestions.

> do we use a different reloc for stubs addresses vs external addresses?

1. will not work. They could be different. Stubs use `runtime_call` relic and `crc` uses `external_word`.

I considered 2. when I worked on this but there is assumption that we have all external addresses recorded when we look for matching address in `AOTCodeAddressTable::id_for_address()`. There is specific assert there. And we have relocation in all stubs and adapters.  I am concern about some concurrency issues if we don't satisfy the assumption.

An other solution would be to have separate `StubRoutines::get_crc_table_addr()` which can be use early by AOT code and later by `generate_initial_stubs()`. It will check local value (StubRoutines::x86::_crc32c_table on x86, for example) and calculate it if needed. 

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3109030825