On Wed, 20 May 2026 23:47:35 GMT, Volodymyr Paprotski <[email protected]>
wrote:
>> src/hotspot/share/opto/library_call.cpp line 8377:
>>
>>> 8375: }
>>> 8376:
>>> 8377: if (!stubAddr) return false;
>>
>> For this -- what I assume is a release-build safety return -- to work,
>> `stubAddress` should be initialized to `nullptr`?
>
> This sent me down quite the rabbit hole, because I do indeed remember having
> to set stubs to `nullptr` by default then override in stubGenerator..
>
> Its all been cleaned up with macros..
>
> In `src/hotspot/cpu/x86/stubRoutines_x86.cpp`:
> ```C++
> #define DEFINE_ARCH_ENTRY(arch, blob_name, stub_name, field_name,
> getter_name) \
> address StubRoutines:: arch :: STUB_FIELD_NAME(field_name) = nullptr;
>
> Comment in `src/hotspot/share/runtime/stubDeclarations.hpp` says as much,
> but I wanted to find the above expansion as proof..:
> ```C++
> // do_entry is used to declare or define a static field of class
> // StubRoutines with type address that stores a specific entry point
> // for a given stub. n.b. the number of entries associated with a stub
> // is often one but it can be more than one and, in a few special
> // cases, it is zero. do_entry is also used to declare and define an
> // associated getter method for the field. do_entry is used to declare
> // fields that should be initialized to nullptr.
> ```
Why the rabbit hole? `stubAddr` is the local here, it is not guaranteed to be
`nullptr`, unless we compile with extra hardening:
bool LibraryCallKit::inline_keccak(vmIntrinsics::ID id) {
address stubAddr;
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31125#discussion_r3278676665
