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

[Andrew Haley]

On Fri, 26 Mar 2021 09:44:19 GMT, Pengfei Li <pli at openjdk.org> wrote:

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

> Vladimir has indicated there is no issue with changing the order as you
> have done so that is fine as far as I am concerned.

OK, then.

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
>>> 3:  * Copyright (c) 2015, 2021, Red Hat Inc. All rights reserved.
>> 
>> Please restore this copyright line unless instructed to update it by Red Hat.
>
> Reverted, thanks.

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

So why not, on the platforms where it's a pain, define a function `VM_Version::get_ContendedPaddingWidth()` that returns the largest value it could be on that platform? On platforms where it's easy to find out, return the true value.

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

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