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

[Vladimir Kozlov]

On Wed, 23 Jul 2025 02:00:43 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:
> 
>   Fixed Zero VM

Here is new version of fix as we discussed.

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

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