RFR: 8364150: RISC-V: Leftover for JDK-8343430 removing old trampoline call [v3]
Fei Yang
fyang at openjdk.org
Mon Jul 28 13:47:56 UTC 2025
On Mon, 28 Jul 2025 13:34:07 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Yes, the `dest` param here holds the address of this stub.
>> In `CallRelocation::fix_relocation_after_move`, we first get the `callee` address by calling `pd_call_destination` which delegates work to `NativeCall::reloc_destination` for a NativeCall. And we have modified `NativeCall::reloc_destination` to return the stub address in this PR at the same time. So `callee` will hold the stub address. Immediatedly after that, `callee` is passed to `pd_set_call_destination` which delegates work to `NativeCall::reloc_set_destination`. Make sense?
>>
>>
>> void CallRelocation::fix_relocation_after_move(const CodeBuffer* src, CodeBuffer* dest) {
>> // Usually a self-relative reference to an external routine.
>> // On some platforms, the reference is absolute (not self-relative).
>> // The enhanced use of pd_call_destination sorts this all out.
>> address orig_addr = old_addr_for(addr(), src, dest);
>> address callee = pd_call_destination(orig_addr); <=========== callee is stub address
>> // Reassert the callee address, this time in the new copy of the code.
>> pd_set_call_destination(callee); <=========== callee passed as param
>> }
>
> There is another call of `Relocation::pd_set_call_destination(address x)` from `CallRelocation::set_destination(address x)`, not sure if this `x` passed in from set_destination is also the stub addr?
Sure, I'll take a look. Thanks.
BTW: I noticed one use of `set_destination` in file ./code/aotCodeCache.cpp. Seems AOT related.
Maybe you can help confirm that while you are working on enabling AOT support on riscv64?
./code/aotCodeCache.cpp: ((CallRelocation*)iter.reloc())->set_destination(dest);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26495#discussion_r2236539009
More information about the hotspot-compiler-dev
mailing list