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

Tue Feb 2 17:46:23 UTC 2021

(dropping Andrew and Aleksey)

On Tue, Feb 2, 2021 at 6:13 PM Ioi Lam <ioi.lam at oracle.com> wrote:

>
>
> 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> 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. 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.
>
>
Oh, I understand. Sorry, I was not clear enough.

What I meant was: os::vm_allocation_granularity() is the OS-dictated
alignment for the start address for memory mappings. We need to know it
wherever we want to predict the mapping address of a future mapping.
Outside of that, there is very little reason to use it instead of using
page size. WIthin the hotspot, it is used all over the place, and a number
of those usages are bewildering and possibly wrong. Hence my original
question, why use it for CDS alignment. But you answered the question, as
long as we mmap the cds regions individually via mmap, we need to do that
with allocation granularity.

Setting it hard wired to 64k sounds pragmatic.

Note that I created https://bugs.openjdk.java.net/browse/JDK-8253683 a
while ago to cleanup usages of os::vm_allocation_granularity(), but never
got along to do this.

> (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.
>
>
Makes perfect sense.

> 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.
>
>
I still think, as in earlier discussions, that mapping it in one go would
be the right way to do.

> 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.
>
>
I agree.

> Thanks
> - Ioi
>
>
>
Cheers, Thomas

> .:Thomas
>
> Thanks
>> - Ioi
>>
>> Cheers, Thomas
>>
>>
>> On Mon, Feb 1, 2021 at 6:20 PM Andrew Haley <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
>>>
>>>
>>
>