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

[Fei Yang]

On Mon, 28 Jul 2025 13:57:08 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> 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);
>
> One suggestion: maybe we can add an additional parameter here for `NativeCall::reloc_set_destination(address dest)` like `is_stub_addr`, so on the path we're sure `dest` is the stub address rather than reloc call destination, we can pass true for `is_stub_addr`, and in other paths we can pass false.
> And we can also add an assert in the `is_stub_addr == true` path, like `assert(CodeCache::contains(x), "must");`.

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.

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

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