RFR(S): 8028107: Kitchensink crashed with EAV
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Dec 3 18:25:47 PST 2013
http://cr.openjdk.java.net/~kvn/8028107/webrev/
https://bugs.openjdk.java.net/browse/JDK-8028107
As I explained in previous mail SharedRuntime::resolve_sub_helper() has
Lock between saving nmethod pointer in local CompiledICInfo variable and
when it is used to create new compiledIC entry.
Lock may block for safepoint during which nmethod can change state: it
can be deoptimized or unloaded.
I looked in other places and did not find anything suspicious. For
example, in handle_ic_miss_helper() compiled entry computation and
compiledIC setting are done under the same lock.
The fix is to check the state of caller and callee nmethods and skip
call site patching if any of them is not alive.
Note, we have strange/swapped names for functions which check nmethod state:
bool is_in_use() const { return _state == alive; }
bool is_alive() const { return _state == alive || _state ==
not_entrant; }
The dest_entry_point assert in resolve_sub_helper() is mostly useless
now but I kept it slightly modified.
I was not able to reproduce the problem running kitchensink for 5 days.
So I can't verify this fix. As I pointed in the bug report this failure
happens about once per year.
I also fixed indention in nmethod.cpp but webrev does not handle such
changes. Here they are:
src/share/vm/code/nmethod.cpp
@@ -1660,8 +1660,8 @@
CompiledICHolder* cichk_oop = ic->cached_icholder();
if
(cichk_oop->holder_method()->method_holder()->is_loader_alive(is_alive) &&
cichk_oop->holder_klass()->is_loader_alive(is_alive)) {
- continue;
- }
+ continue;
+ }
} else {
Metadata* ic_oop = ic->cached_metadata();
if (ic_oop != NULL) {
@@ -1677,8 +1677,8 @@
ShouldNotReachHere();
}
}
- }
- ic->set_to_clean();
+ }
+ ic->set_to_clean();
}
}
}
Thanks,
Vladimir
More information about the hotspot-compiler-dev
mailing list