JVMCI calling register_nmethod without CodeCache lock

When running a CompileTheWorld test using Graal and libGraal, we are hitting a guarantee caused by a missing lock on the CodeCache when registerring an nmethod.

Here is a proposed fix:

diff --git a/src/hotspot/share/jvmci/jvmciRuntime.cpp b/src/hotspot/share/jvmci/jvmciRuntime.cpp
--- a/src/hotspot/share/jvmci/jvmciRuntime.cpp
+++ b/src/hotspot/share/jvmci/jvmciRuntime.cpp
@@ -668,6 +668,7 @@
 
   // Since we've patched some oops in the nmethod,
   // (re)register it with the heap.
+ MutexLocker ml(CodeCache_lock, Mutex::_no_safepoint_check_flag);
   Universe::heap()->register_nmethod(nm);
 }

Here is the crash output:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (heapRegionRemSet.cpp:459), pid=36332, tid=36346
# guarantee(!_code_roots.contains(nm)) failed: duplicate entry found
#
# JRE version: Java(TM) SE Runtime Environment Server VM Graal:compiler_9692d20aac4f22c736dded0b94aab16fc4e9ed50 (15.0) (build 15-internal+0-2020-07-21-1834055.bvandett...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM Server VM Graal:compiler_9692d20aac4f22c736dded0b94aab16fc4e9ed50 (15-internal+0-2020-07-21-1834055.bvandett..., mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x729054] HeapRegionRemSet::remove_strong_code_root(nmethod*)+0xa4
#
# Core dump will be written. Default location: Core dumps may be processed with “/usr/share/apport/apport %p %s %c %d %P %E” (or dumping to /export/users/bobv/bitbucket/graal/vm/core.36332)
#
# An error report file with more information is saved as:
# /export/users/bobv/bitbucket/graal/vm/hs_err_pid36332.log
Compiled method (JVMCI) 26076 45372 4 sun.net.www.MessageHeader::canonicalID (99 bytes)
 total in heap [0x00007f4ec5fe4990,0x00007f4ec5fe5068] = 1752
 relocation [0x00007f4ec5fe4ae8,0x00007f4ec5fe4b40] = 88
 main code [0x00007f4ec5fe4b40,0x00007f4ec5fe4e60] = 800
 stub code [0x00007f4ec5fe4e60,0x00007f4ec5fe4ec0] = 96
 oops [0x00007f4ec5fe4ec0,0x00007f4ec5fe4ec8] = 8
 metadata [0x00007f4ec5fe4ec8,0x00007f4ec5fe4ed0] = 8
 scopes data [0x00007f4ec5fe4ed0,0x00007f4ec5fe4f40] = 112
 scopes pcs [0x00007f4ec5fe4f40,0x00007f4ec5fe4fc0] = 128
 dependencies [0x00007f4ec5fe4fc0,0x00007f4ec5fe4fc8] = 8
 handler table [0x00007f4ec5fe4fc8,0x00007f4ec5fe5058] = 144
 JVMCI data [0x00007f4ec5fe5058,0x00007f4ec5fe5068] = 16