When chasing down a performance regression in Leyden/premain, I realized that JDK-8350209 came with the bootstrapping problem by checking the AOT cache status way too early. Before full AOT cache init sequence runs, these checks would always reply that AOT cache is off. In mainline, I suspect this causes initial stubs to never practically restored/dumped. We picked up that problem in Leyden/premain as well, where it manifests as C1/C2 preloading threads not starting at all (JDK-8358693).

Here is the excerpt of our current init code:

jint init_globals() {
  ...
  // premain asks AOTCodeCache::is_code_load_thread_on() to decide whether to start AOT load threads
  compilationPolicy_init();  
  ...
  // Initial stubs get restored/dumped here, consulting AOTCache::open_for_use()/open_for_dump()
  SharedRuntime::generate_initial_stubs();
  ...
  // AOTCache::initialize runs here
  jint status = universe_init(); 
  ...
 
  // cache is published here after JDK-8357175.
  // From this moment on, the AOT cache status checks are trustworthy
  AOTCodeCache::init2();     

Apply the attached patch, and observe it fail even during the build. There might be more cases, but I was not able to run full test suite, given how it fails during the build.