RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to preuniverse stubs [v3]

[Andrew Dinn]

On Wed, 23 Jul 2025 21:26:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Rework the fix

src/hotspot/cpu/zero/stubDeclarations_zero.hpp line 40:

> 38:                                       do_arch_entry,                    \
> 39:                                       do_arch_entry_init)               \
> 40:   do_arch_blob(initial, 32)                                             \

Do we need this any more?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2227698445