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

Chad Rakoczy duke at openjdk.org
Thu May 8 20:01:56 UTC 2025


On Fri, 25 Apr 2025 22:49:55 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> ~I did this because during code buffer expansion `pd_set_call_destination` gets called but there is no relocation info at that time. So with debug builds it was incorrectly trying to find a trampoline stub that did not exist yet because it believed it needed to when it didn't. I agree this is probably not the best approach though and I will look for a better solution~
>
> Actually the issue is not during code buffer expansion. It's called when creating a new nmethod that I can only get to occur when using the Graal compiler. So it may not be true that calls always have trampolines in the case of Graal. This _fix_ may just make the bug harder to encounter

For debug builds Hotspot uses the 2M range to determine if there should be a trampoline or not for a call. Graal uses 128M regardless of debug or release builds. This means that Graal compiled methods may not have trampolines but this check will expect them too. I reverted this change as it just means there is a difference on how Graal and Hotspot determine max branch range

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

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


More information about the hotspot-compiler-dev mailing list