RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to preuniverse stubs [v2]
Yudi Zheng
yzheng at openjdk.org
Thu Jul 24 13:25:57 UTC 2025
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
src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 420:
> 418: static_field(StubRoutines, _dilithiumDecomposePoly, address) \
> 419: static_field(StubRoutines, _updateBytesCRC32, address) \
> 420: static_field(StubRoutines, _crc_table_addr, address) \
Could you please export via `CompilerToVM::Data`?
diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
index 41531b083fc..71331b578a5 100644
--- a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
+++ b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
@@ -131,6 +131,8 @@ class CompilerToVM {
static address dlog10;
static address dpow;
+ static address crc_table_addr;
+
static address symbol_init;
static address symbol_clinit;
diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
index b6d919fdfe9..8a1a02d62b3 100644
--- a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
+++ b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
@@ -151,6 +151,8 @@ address CompilerToVM::Data::dlog;
address CompilerToVM::Data::dlog10;
address CompilerToVM::Data::dpow;
+address CompilerToVM::Data::crc_table_addr;
+
address CompilerToVM::Data::symbol_init;
address CompilerToVM::Data::symbol_clinit;
@@ -289,6 +291,7 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
SET_TRIGFUNC_OR_NULL(dtanh);
SET_TRIGFUNC_OR_NULL(dcbrt);
+ SET_TRIGFUNC_OR_NULL(crc_table_addr);
#undef SET_TRIGFUNC_OR_NULL
diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 1408cb09b0a..88d098468e9 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -147,6 +147,7 @@
static_field(CompilerToVM::Data, dlog, address) \
static_field(CompilerToVM::Data, dlog10, address) \
static_field(CompilerToVM::Data, dpow, address) \
+ static_field(CompilerToVM::Data, crc_table_addr, address) \
\
static_field(CompilerToVM::Data, symbol_init, address) \
static_field(CompilerToVM::Data, symbol_clinit, address) \
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228514289
More information about the graal-dev
mailing list