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