RFR: 8316694: Implement relocation of nmethod within CodeCache [v24]

[Chad Rakoczy]

On Tue, 17 Jun 2025 21:20:15 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> What do you mean by this? I don't see how recursive calls would behave differently. There is a check for intra-nmethod calls which I think would cover this case
>> 
>> OK, I didn't see that check when I took a quick look.  If it already works as intended, great.
>
>> We still need this check in the event that there is a direct call that no longer reaches.
> 
> OK, I didn't realize that was what Relocation::pd_set_call_destination() was doing.  I think it would be better for the CPU-specific code to take care of that, rather than the shared code.  We already have functions like NativeCall::set_destination_mt_safe() that do the right thing regarding trampolines.  I think this could be refactored into a commonm function that Relocation::pd_set_call_destination() could also use.  Sorry for the churn, but hopefully we are converging on a solution.  I thought I had done the refactoring for 8321509, but it looks like I went with the simply fix at the time of adding a parameter to set_destination_mt_safe() to make it lock-free.

Thanks for the suggestion. I updated to use `set_destination_mt_safe()` instead ([reference](https://github.com/openjdk/jdk/pull/23573/commits/b02e8bdb63db8042418b92ade4a26647e4e2dd8b))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2157797060