[External] : Re: AArch64 OpenJDK bootstrap failure on head

[Ioi Lam]

On 2/2/21 1:32 AM, Thomas Stüfe wrote:
>
>
> On Mon, Feb 1, 2021 at 10:11 PM Ioi Lam <ioi.lam at oracle.com 
> <mailto:ioi.lam at oracle.com>> wrote:
>
>     On 2/1/21 9:36 AM, Thomas Stüfe wrote:
>>     This does not solve the alignment problem, but I don't like
>>     that we unconditionally print a message here since this is a
>>     non-fatal error. Also, CDS mapping may fail for other reasons,
>>     for which we do not print unconditionally. I think we should make
>>     this info log level:
>>
>>     --- a/src/hotspot/share/memory/metaspaceShared.cpp
>>     +++ b/src/hotspot/share/memory/metaspaceShared.cpp
>>     @@ -1725,7 +1725,7 @@ MapArchiveResult
>>     MetaspaceShared::map_archive(FileMapInfo* mapinfo, char* mapped
>>        mapinfo->set_is_mapped(false);
>>
>>        if (mapinfo->alignment() !=
>>     (size_t)os::vm_allocation_granularity()) {
>>     -    log_error(cds)("Unable to map CDS archive --
>>     os::vm_allocation_granularity() expected: " SIZE_FORMAT
>>     +    log_info(cds)("Unable to map CDS archive --
>>     os::vm_allocation_granularity() expected: " SIZE_FORMAT
>>                         " actual: %d", mapinfo->alignment(),
>>     os::vm_allocation_granularity());
>>          return MAP_ARCHIVE_OTHER_FAILURE;
>>        }
>>
>>     @ Ioi, does that make sense?
>>
>
>     Yes, your fix makes sense.
>
>
> Thanks. https://github.com/openjdk/jdk/pull/2348 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/2348__;!!GqivPVa7Brio!LRn8UjBQlnYs4XgafXHxU7RUqFZZx-Y19XBMcwy44BEjEXSIBS1GBrWKZ6pwcw$>
>
>     This issue is being address in
>     https://bugs.openjdk.java.net/browse/JDK-8236847
>     <https://bugs.openjdk.java.net/browse/JDK-8236847>. We will
>     probably unconditionally change the alignment to 64KB for AARCH64,
>     as well as MacOS (so that you can run a X64 JDK on M1 using Rosetta).
>
>
> I thought so too. I also see it being used for region-to-region 
> alignment, where I believe page size would be sufficient?
>

The problem in JDK-8236847 
<https://bugs.openjdk.java.net/browse/JDK-8236847> happens when you 
create a CDS archive on one machine, and use it on another, and the two 
machines have different page sizes.

(a) linux/aarch64 can be configured to have either 4KB or 64KB page sizes
(b) macOS/x64 uses 4KB, but macOS/aarch64 uses 64KB

So if you create the archive on a machine with 4KB page size, your RW 
region may start at (64KB * N + 4KB), and this region cannot be mapped 
directly on a machine with 64KB sizes.

My proposal is to always align the CDS regions by 64KB on these 
platforms, so they can always be mapped under all circumstances.

Alternatives are: use read() instead of mmap; or, instead of mmaping the 
individual regions, mmap all of them at once (assuming that the first 
region, MC, is 64KB aligned). Either solution will reduce the 
possibility of sharing, and make the code more complicated.

Since the CDS archive is at least 10MB in size, adding 3 extra padding 
areas of up to 64KB each doesn't seem that outrageous in file size. 
There's no change in physical memory usage since we never touch the 
padding area.

Thanks
- Ioi


> .:Thomas
>
>     Thanks
>     - Ioi
>
>>     Cheers, Thomas
>>
>>
>>     On Mon, Feb 1, 2021 at 6:20 PM Andrew Haley <aph at redhat.com
>>     <mailto:aph at redhat.com>> wrote:
>>
>>         On 2/1/21 5:14 PM, Aleksey Shipilev wrote:
>>         > On 2/1/21 4:38 PM, Andrew Haley wrote:
>>         >> but that doesn't work either. Any ideas? I'm really stuck.
>>         >
>>         > Did you "make clean" after changing any of the configure
>>         files and/or configure arguments? I.e. did
>>         > AWTIcon32_java_icon16_png actually regenerate?
>>
>>         Many times.
>>
>>         > Prepending the build with "LOG=debug" would tell what
>>         cmdlines are used at every step of build process.
>>
>>         Sure, I can see what it's doing. I think this is actually a
>>         regression
>>         caused by the Windows-AArch64 port. I'll do some bisecting.
>>
>>         -- 
>>         Andrew Haley  (he/him)
>>         Java Platform Lead Engineer
>>         Red Hat UK Ltd. <https://www.redhat.com
>>         <https://urldefense.com/v3/__https://www.redhat.com__;!!GqivPVa7Brio!MzT8lD4heOPkWgVBap3cDC2aM4W8zJ1wWS_-PVlTdPwr96wHRafdO7zjS2x2qQ$>>
>>         https://keybase.io/andrewhaley
>>         <https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!GqivPVa7Brio!MzT8lD4heOPkWgVBap3cDC2aM4W8zJ1wWS_-PVlTdPwr96wHRafdO7wP-EZNow$>
>>         EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>
>