RFR: 8321509: False positive in get_trampoline fast path causes crash [v3]

[Andrew Dinn]

On Tue, 25 Jun 2024 23:49:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> 8321509: False positive in get_trampoline fast path causes crash
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

This solution looks ok to me as far as jdk mainline is concerned. However, I think there is a problem as far Leyden is concerned.

The code changes Relocation::pd_call_destination to always expect its associated call to be embedded within an nmethod when orig_addr is null (i.e. when it is called with no args as reloc.pd_call_destination()). This is where the problem arises.

Currently, Leyden calls Relocation::pd_call_destination() from CallRelocation::destination() (and also from trampoline_stub_Relocation::destination()) when storing an nmethod to the CDS code cache. It needs to do this in order to be able to track relocs of type virtual_call_type, opt_virtual_call_type, static_call_type and runtime_call_type (also trampoline_stub_type). That is because all these relocs need their call destination to be adjusted when the nmethod is restored from the CDS code cache.

However, we already have prototype code in Leyden to store generated blobs to the CDS code cache. These blobs may legitimately include runtime_call_type relocs which also need tracking and adjusting at restore. For example, shared runtime or compiler stubs may call out to the JVM. Likewise, stubs in a stub generator blob may need to call out to the JVM or to a stub in some earlier generated blob. So, Leyden will need to call CallRelocation::destination() in cases where the associated call is embedded in a non-nmethod. Note that these calls will never employ trampolines.

The obvious fix is to modify Relocation::pd_call_destination so that it drops through to call MacroAssembler::pd_call_destination if the incoming blob is not an nmethod.

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

PR Comment: https://git.openjdk.org/jdk/pull/19796#issuecomment-2202824961