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

[Pengfei Li]

On Thu, 25 Mar 2021 04:22:11 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> 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()`.

> It may be possible to factor out the necessary logic to the VM_Version::early_initialize() function instead.

Personally I didn't see it's possible. `VM_Version::early_initialize()` is called too early. As I mentioned above. On some architectures (typically arm32, ppc and s390), code is emitted into a code buffer to query the CPU dcache line size info. And this depends on `CodeCache::initialize()`. So we still need to place the necessary logic after `CodeCache::initialize()`.

Please let me know if you have other suggestions.

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

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