RFR: 8258229: Crash in nmethod::reloc_string_for

[Manuel Hässig]

On Mon, 28 Apr 2025 15:43:11 GMT, Galder Zamarreño <galder 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.
>
> test/hotspot/jtreg/compiler/print/TestPrintAssemblyDeoptRace.java line 28:
> 
>> 26:  * @bug 8258229
>> 27:  * @summary If a method is made not entrant while prinint the assembly, hotspot crashes due to mismatched relocation information.
>> 28:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:CompileCommand=print,java/math/BitSieve.bit
> 
> Shouldn't the test run with `-XX:+DeoptimizeALot`? That way we would get more confidence that the deoptimization support works as expected.

That is a good point. I'll add it in v2.

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

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