On Thu, 21 May 2026 04:35:50 GMT, Aleksey Shipilev <[email protected]> wrote:
>> 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;
Also, I think `assert(false, "dont call");` need to be `ShouldNotReachHere()`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31125#discussion_r3279704929
