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

Vladimir Kozlov kvn at openjdk.org
Tue Jul 9 18:45:17 UTC 2024


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

I will let Dean answer Evgeny.

Here is result of my investigation. I think we can replace `nmethod::stubs_comtains()` with `CodeBlob::code_contains()` to check for trampoline code:


address NativeCall::destination() const {
  address addr = instruction_address();
  address destination = addr + displacement();

  // Performance optimization: no need to call find_blob() if it is a self-call
  if (destination == addr) {
    return destination;
  }
  // Do we use a trampoline stub for this call?
  CodeBlob* cb = CodeCache::find_blob(addr);
  assert(cb != nullptr, "CodeBlob expected");
  if (cb->code_contains(destination) && is_NativeCallTrampolineStub_at(destination)) {
    // Yes we do, so get the destination from the trampoline stub.
    const address trampoline_stub_addr = destination;
    destination = nativeCallTrampolineStub_at(trampoline_stub_addr)->destination();
  }

  return destination;
}

This pass Leyden testing.

My concern with simply returning raw address when it is not `nmethod` could be incorrect for Leyden case when we process `CodeBuffer` which contains code layout similar to `nmethod` and we can have trampoline call.

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

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


More information about the hotspot-compiler-dev mailing list