RFR: 8264006: Fix AOT library loading on CPUs with 256-byte dcache line

[Pengfei Li]

Recently we tested OpenJDK on some CPUs with 256-byte dcache line size.
HotSpot AOT tests failed because the shared library compiled with the
same VM options on the same machine are skipped when loaded back.

Below command sequence shows a simple way to reproduce this issue.

$ getconf -a | grep LEVEL1_DCACHE_LINESIZE
LEVEL1_DCACHE_LINESIZE 256

$ jaotc --output a.so Hello.class

$ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:AOTLibrary=./a.so -XX:+PrintAOT Hello
Shared file ./a.so error: ContendedPaddingWidth has different value '256' from current '128'
      4 1 skipped ./a.so aot library

The default value of VM option `ContendedPaddingWidth` is 128. But on CPUs
with L1 dcache line size larger than 128 bytes, the value is adjusted to
the cache line size in `VM_Version_init()`. This adjustment is done after
AOT library loading in `codeCache_init()`. So the AOT lib verifier still
assumes the `ContendedPaddingWidth` in the compiled library should be 128
and thus causes the loaded library skipped.

In my proposed fix, `AOTLoader::initialize()` is moved out of the general
codecache initialization and placed after `VM_Version_init()`. The order
of `codeCache_init()` and `VM_Version_init()` is not changed since there may
be code emitted during `VM_Version_init()`, which depends on the general
codecache init.

Tested `hotspot::hotspot_all_no_apps`, `jdk::jdk_core` and `langtools::tier1`.

-------------

Commit messages:
 - 8264006: Fix AOT library loading on CPUs with 256-byte dcache line

Changes: https://git.openjdk.java.net/jdk/pull/3169/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3169&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264006
  Stats: 11 lines in 4 files changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3169/head:pull/3169

PR: https://git.openjdk.java.net/jdk/pull/3169