On 2/2/21 1:32 AM, Thomas Stüfe wrote:
On Mon, Feb 1, 2021 at 10:11 PM Ioi Lam <ioi....@oracle.com
<mailto:ioi....@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 <a...@redhat.com
<mailto:a...@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
