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

[Andrew Haley]

On Wed, 24 Mar 2021 08:04:47 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`.

I must confess I don't like this solution at all: it sounds very delicate. Couldn't you define a function `VM_Version::get_ContendedPaddingWidth()`and call that?

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

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