RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash
Tom Rodriguez
never at openjdk.java.net
Wed May 4 16:34:48 UTC 2022
On Wed, 4 May 2022 07:47:28 GMT, Dean Long <dlong at openjdk.org> wrote:
> This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI.
> See https://bugs.openjdk.java.net/browse/JDK-8283306 for details.
I think a formulation more like this makes it clearer. I'm not sure I agree with the assert/guarantee in the default path since it seems overly specific.
if (call_addr != NULL) {
// On x86 the logic for finding a call instruction is blindly checking for a call opcode 5
// bytes back in the instruction stream so we must also check for reloc info.
RelocIterator iter(caller_nm, call_addr, call_addr+1);
int ret = iter.next(); // Get item
if (ret) {
bool is_static_call = false;
switch (iter.type()) {
case relocInfo::static_call_type:
is_static_call = true;
case relocInfo::virtual_call_type:
case relocInfo::opt_virtual_call_type:
// Cleaning the inline cache will force a new resolve. This is more robust
// than directly setting it to the new destination, since resolving of calls
// is always done through the same code path. (experience shows that it
// leads to very hard to track down bugs, if an inline cache gets updated
// to a wrong method). It should not be performance critical, since the
// resolve is only done once.
guarantee(iter.addr() == call_addr, "must find call");
for (;;) {
ICRefillVerifier ic_refill_verifier;
if (!clear_ic_at_addr(caller_nm, call_addr, is_static_call)) {
InlineCacheBuffer::refill_ic_stubs();
} else {
break;
}
}
break;
default:
guarantee(!UseInlineCaches || caller_nm->is_compiled_by_jvmci(), "relocation info. must exist for this address");
}
}
}
-------------
PR: https://git.openjdk.java.net/jdk/pull/8528
More information about the hotspot-dev
mailing list