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

[Pengfei Li]

On Wed, 24 Mar 2021 21:37:14 GMT, Vladimir Kozlov <kvn 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`.
>
> looks fine from compiler/aot POV.

> 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?

Hi Andrew, I agree that tuning the initialization order is a tricky fix to some extent. But I don't think it's a trivial work to define a function to get the final value of `ContendedPaddingWidth` before `VM_Version::initialize()`. As the value depends on CPU dcache line size, the problem is that the way querying that CPU size info varies significantly on different platforms. In current implementation, we run a few assembly code on AArch64. But on some other architectures, typically ppc and s390, we emit much more code into a code buffer (and thus depends on `CodeCache::initialize()`). And on Windows, we need to call some Windows API to retrieve processor info. If we do too much in the newly defined function, it would be no much difference from moving `VM_Version::initialize()` before `AOTLoader::initialize()`.

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

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