RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]

[Andrew Dinn]

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

@shqking Thank you for testing and reporting the issue and also for noticing the missing copyright updates.

The assertion is happening because the arm-specific stub declarations are inconsistent. The entry declaration for `atomic_store_long_entry` claims it belongs to stub `atomic_load_long` but the current stub is actually `atomic_store_long`.

I will push a patch to fix that and another one for the copyrights.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027247244