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

[Andrew Haley]

On Thu, 25 Mar 2021 09:06:07 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> 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`.
>
> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Red Hat copyright line

Marked as reviewed by aph (Reviewer).

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

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