Noticed by [~dlong] while discussing JDK-8369219. I didn't observe this, but it seems technically possible that the nmethod which is made not entrant is not the expected one.

> Actually, I think there is a separate race here. It seems possible that the code() value we read could actually be the
   new wrapper stub, or one of multiple old versions. To make sure no old version is ever lost, it seems like we would
   need to use atomic swap when setting the code() value.

> OK let's assume CompileBroker prevents creating multiple wrappers, but what prevents a race between
   AdapterHandlerLibrary::create_native_wrapper() and Method::set_native_function()?
   1. thread 2 calls create_native_wrapper for the old native function
   2. thread 1 calls set_native_function and changes Method::native_function() from underneath the create_native_wrapper call
   3. thread 2 creates code() for the new native function
   4. thread 1 reads code() and calls make_not_entrant() for the new wrapper