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

[Hamlin Li]

On Tue, 29 Jul 2025 00:45:00 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I intend to think that by design we only want `NativeCall::reloc_destination` and `NativeCall::reloc_set_destination` to get and set stub address. There are other functions like `NativeCall::destination`, `NativeCall::set_destination` and `NativeCall::set_destination_mt_safe` which are supposed to deal with the real call target. So I am going to check the `CallRelocation::set_destination` cases in shared code as you mentioned.
>
> Here is what I find. There are only two use cases of `CallRelocation::set_destination(address x)` in hotspot shared code. One is the AOT case [1] and the other is `CallRelocation::set_value(address x)` [2]. And `CallRelocation::set_value(address x)` is never used. Given that we don't have AOT support for riscv64 in JDK upstream yet, I think we are safe.
> 
> And I have added assertion in `CallRelocation::set_value(address x)` about `dest` param to make sure it's the same as the stub address. I see `hs:tier1` still test good with fastdebug build. Also I think it's better to investigate and fix the AOT use case in Leyden premain as you are currently working on if it turns out to be an issue. Does that work for you?
> 
> 
> ./relocInfo.hpp:  void     set_value(address x) override    { set_destination(x); }
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/aotCodeCache.cpp#L1111
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/relocInfo.hpp#L955

Thanks for investigating. The pr makes sense to me. Can you just help to add an TODO or FIXUP here to state that during the implementation of aot series, we might need to revisit here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26495#discussion_r2239358922