RFR: 8364150: RISC-V: Leftover for JDK-8343430 removing old trampoline call [v2]

[Hamlin Li]

On Mon, 28 Jul 2025 12:58:21 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this small change.
>> 
>> JDK-8343430 removed the old trampoline call on RISC-V. And the new solution (reloc call) loads a target address from stub section and do an indirect call. This means the stub is always there for a NativeCall. So there's no need to check existence of the stub when doing `CallRelocation::fix_relocation_after_move` [1].
>> 
>> We can always return the stub address in `NativeCall::reloc_destination` and use that address in `NativeCall::reloc_set_destination`. This helps simplify the code and saves one `MacroAssembler::target_addr_for_insn` call
>> and one `trampoline_stub_Relocation::get_trampoline_for` call in these two functions respectively.
>> 
>> Testing on linux-riscv64:
>> - [x] tier1-tier3 (release build)
>> - [x] hs:tier1-hs:tier3 (fastdebug build)
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/relocInfo.cpp#L404-L406
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment

Thanks for working on this!
There are several comments below.

src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 116:

> 114:   if (code->is_nmethod()) {
> 115:     assert(dest != nullptr, "Sanity");
> 116:     MacroAssembler::pd_patch_instruction_size(call_addr, dest);

`dest` here is the reloc call desitnation, ie. the dest stored in the stub, and it should be able to reach anywhere in the address space.
The patch here should patch the `auipc + jalr` to the address of this stub, rather than `dest`?

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

PR Review: https://git.openjdk.org/jdk/pull/26495#pullrequestreview-3062577961
PR Review Comment: https://git.openjdk.org/jdk/pull/26495#discussion_r2236343787