RFR: 8258229: Crash in nmethod::reloc_string_for

[Marc Chevalier]

On Wed, 23 Apr 2025 15:12:54 GMT, Manuel Hässig <duke at openjdk.org> wrote:

> ## Issue Summary
> 
> The issue manifests in intermittent failures of test cases with `-XX:+PrintAssembly`. The reason for these intermittent failures is a deoptimization of the method before or during printing its assembly. In case that deoptimization makes the method not entrant, then the entry of that method is patched, but the relocation information is not updated. If the instruction at the method entry before patching had relocation info that prints a comment during assembly printing, printing that comment for the patched entry fails in case the operands of the original and patched instructions do not match.
> 
> ## Change Summary
> 
> To fix this issue, this PR updates the relocation info when patching the method entry. To avoid any races between printing and deoptimizing, this PR acquires the`NMethodState_lock`for printing an `nmethod`.
> 
> All changes of this PR summarized:
>  - add a regression test,
>  - update the relocation information after patching the method entry for making it not entrant,
>  - acquire the `NMethodStat_lock` in `print_nmethod()` to avoid changing the relocation information during printing.
> 
> ## Testing
> 
> I ran tiers 1 through 3 and Oracle internal testing.

src/hotspot/share/code/nmethod.cpp line 1650:

> 1648: 
> 1649: void nmethod::print_nmethod(bool printmethod) {
> 1650:   // Enter a critical section to prevent a race with deopts that patch code and updates the relocation info.

I came exactly to check for race conditions, suspecting we need locks or atomicity given the comment on `patch_verified_entry`. Nice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24831#discussion_r2057743555