The compiled method unload events save the code_start and jmethodID, and due to previous changes to keep nmethod from being unloaded and zombied, the nmethod compiled method load and unload events will be properly ordered.

So the nmethodLocker is unneeded.

Erik Österlund 12:47 PM: Why the nmethodLocker is problematic:

It is an effort of reducing the different flavours of dead nmethods, in order to make it easier to reason about the code. We have unloaded, zombie, and things that are none of the two that are is_unloading(), and then we have zombies that are is_unloading(), and then on top of that nmethod locker adds yet another dimension to the flavours of dead, where all of said states exist with zero and non-zero reference counters. We have had obscure bugs that occur only with JVMTI deferred events because it twists the life cycle slightly in ways that nobody thought about, because it is actually impossible to think about all these different flavours of dead. For example, we almost always prevent nmethod locked nmethods from transitioning from is_alive() to !is_alive(), except if the reason it died is that it became unloaded.

By keeping things alive through tracing (the iterators), then we have fewer flavours of dead nmethods (they become neither zombie nor unloaded), and its easier to know what happens.