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

[Pengfei Li]

On Thu, 25 Mar 2021 07:42:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 dholmes (Reviewer).

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

@theRealAph Just wondering if you have other solutions or advice?

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

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