RFR: 8363837: Make StubRoutines::crc_table_adr() into platform-specific method

[Vladimir Kozlov]

On Wed, 23 Jul 2025 15:42:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> 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?
>
>> Another 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.
> 
> Yes, I think it would be much better if we removed the entry declarations for `crc_table_adr` and `crc32c_table_addr` from stubDeclarations.hpp and instead always looked up the address using a getter method declared in the shared header and implemented in each arch.
> 
> We don't need a generated field in class StubRoutines nor any way to track the value as we do for real generated addresses. So, using the declaration mechanism was the wrong way to do this.

Thank you @adinn

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

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