Temp branch for merging JEP 483 into leyden/premain

[ioi.lam at oracle.com]

As mentioned in today's Leyden meeting, I have merged JEP 483 into 
premain in my local repo. Since there are some new failures, I've put 
the merged version in a temporary branch:

https://github.com/openjdk/leyden/tree/premain-temp-merge-after-jep-483

[1] I have disabled some of the new CDS optimizations. See cdsConfig.cpp

     // FIXME -- leyden+JEP483 merge {
     FLAG_SET_ERGO(ArchiveDynamicProxies, false);
     FLAG_SET_ERGO(ArchiveLoaderLookupCache, false);
     FLAG_SET_ERGO(ArchivePackages, false);
     FLAG_SET_ERGO(ArchiveProtectionDomains, false);
     FLAG_SET_ERGO(ArchiveReflectionData, false);

The reason is that JEP 483 is more aggressive in picking classes to be 
AOT-initialized. For example, with the -XX:+ArchiveProtectionDomains 
option, after the 483 merge, the jdk.internal.loader.NativeLibraries 
class is AOT-initialized. As a result, the static field 
nativeLibraryLockMap is archived, so it remembers all the native libs 
that were loaded during the assembly phase. When we attempt to load 
these libs again during production, we get an "is being loaded in 
another classloader" error.

Therefore, we need more refactoring of the core libraries (such as 
adding runtimeSetup() methods) before some of these optimizations can be 
enabled again.

[2] There's a new failure in the AOT compiler. Could someone familiar 
with the compiler take a look?

#  Internal Error 
(/opt/mach5/mesos/work_dir/slaves/3fe4557b-066a-4392-9b05-ef874140c35c-S62/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/cfba4e4e-51a1-47f1-9d82-c6f09de94dd2/runs/e5810681-4ef9-46d2-9b14-5ef945fda550/workspace/open/src/hotspot/share/code/SCCache.cpp:4205), 
pid=1235, tid=1253
#  fatal error: Address 0x00007fe4817c5d30 for <unknown> is missing in 
SCA table

V  [libjvm.so+0x366795]  SCAddressTable::id_for_address(unsigned char*, 
RelocIterator, CodeBuffer*) [clone .part.0]+0x455 (SCCache.cpp:4205)
V  [libjvm.so+0x36df0a]  SCCache::write_relocations(CodeBuffer*, 
unsigned int&)+0x68a  (SCCache.cpp:4147)
V  [libjvm.so+0x3702d2]  SCCache::write_nmethod(methodHandle const&, 
int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, 
CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, 
ImplicitExceptionTable*, AbstractCompiler*, CompLevel, bool, bool, bool, 
bool, bool, bool)+0xb92  (SCCache.cpp:3335)
V  [libjvm.so+0x3707b2]  SCCache::store_nmethod(methodHandle const&, 
int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, 
CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, 
ImplicitExceptionTable*, AbstractCompiler*, CompLevel, bool, bool, bool, 
bool, bool, bool)+0x182  (SCCache.cpp:3102)
V  [libjvm.so+0x96ac99]  ciEnv::register_method(ciMethod*, int, 
CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, 
ImplicitExceptionTable*, AbstractCompiler*, bool, bool, bool, bool, 
bool, bool, int, bool, SCCEntry*)+0xcf9  (ciEnv.cpp:1099)
V  [libjvm.so+0x161c22e]  PhaseOutput::install_code(ciMethod*, int, 
AbstractCompiler*, bool, bool)+0x15e  (output.cpp:3445)
V  [libjvm.so+0xa9f46b]  Compile::Code_Gen()+0x5cb (compile.cpp:3036)
V  [libjvm.so+0xaa216f]  Compile::Compile(ciEnv*, ciMethod*, int, 
Options, DirectiveSet*)+0x1c7f  (compile.cpp:886)
V  [libjvm.so+0x8dfde1]  C2Compiler::compile_method(ciEnv*, ciMethod*, 
int, bool, DirectiveSet*)+0x261  (c2compiler.cpp:172)
V  [libjvm.so+0xaaff07] 
CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcb7 
(compileBroker.cpp:2626)
V  [libjvm.so+0xab2448] CompileBroker::compiler_thread_loop()+0x758 
(compileBroker.cpp:2272)
V  [libjvm.so+0xfac4ce]  JavaThread::thread_main_inner()+0xee 
(javaThread.cpp:774)

On Linux/x64, this can be reliably reproduced with 
test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java#leyden

On aarch64 (Linux or MacOS), this failure seems to affect many more test 
cases. Also, instead of <unknown>, we see

#  Internal Error (SCCache.cpp:4159), pid=87789, tid=28419
#  fatal error: Address 0x0000000114d4aa80 for 
Stub:_large_arrays_hashcode_boolean is missing in SCA table

Thanks

- Ioi