8268524: nmethod::post_compiled_method_load_event racingly called on zombie

Reviewed-by: kvn, neliasso, coleenp
This commit is contained in:
Erik Österlund 2021-06-22 15:20:10 +00:00
parent 01f12fba64
commit 9ec7180f1e
2 changed files with 16 additions and 4 deletions

View File

@ -1596,8 +1596,18 @@ void nmethod::post_compiled_method_load_event(JvmtiThreadState* state) {
// Don't post this nmethod load event if it is already dying
// because the sweeper might already be deleting this nmethod.
if (is_not_entrant() && can_convert_to_zombie()) {
return;
{
MutexLocker ml(CompiledMethod_lock, Mutex::_no_safepoint_check_flag);
// When the nmethod is acquired from the CodeCache iterator, it can racingly become zombie
// before this code is called. Filter them out here under the CompiledMethod_lock.
if (!is_alive()) {
return;
}
// As for is_alive() nmethods, we also don't want them to racingly become zombie once we
// release this lock, so we check that this is not going to be the case.
if (is_not_entrant() && can_convert_to_zombie()) {
return;
}
}
// This is a bad time for a safepoint. We don't want

View File

@ -227,8 +227,10 @@ jvmtiError JvmtiCodeBlobEvents::generate_compiled_method_load_events(JvmtiEnv* e
{
NoSafepointVerifier nsv; // safepoints are not safe while collecting methods to post.
{
// Walk the CodeCache notifying for live nmethods, don't release the CodeCache_lock
// because the sweeper may be running concurrently.
// Walk the CodeCache notifying for live nmethods. We hold the CodeCache_lock
// to ensure the iteration is safe and nmethods are not concurrently freed.
// However, they may still change states and become !is_alive(). Filtering
// those out is done inside of nmethod::post_compiled_method_load_event().
// Save events to the queue for posting outside the CodeCache_lock.
MutexLocker mu(java_thread, CodeCache_lock, Mutex::_no_safepoint_check_flag);
// Iterate over non-profiled and profiled nmethods