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

[Fei Yang]

On Tue, 29 Jul 2025 10:40:45 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> 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?
> My concern is existing test might or might not catch the issue, currently I'm not sure, so it's better to have a label here to catch the attention at that time, so I will review the related shared code in more details when implement the riscv part.

Sure. I have added TODO comments for both functions. Let me know. Thanks.

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

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