JDK-8236847 : CDS archive with 4K alignment unusable on machines with 64k pages
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2020-01-09
  • Updated: 2024-05-08
  • Resolved: 2021-03-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17
11.0.12-oracleFixed 17 b14Fixed
Related Reports
Blocks :  
JDK-8243392 - Remodel CDS/Metaspace storage reservation
Relates :  
JDK-8263465 - JDK-8236847 causes tier1 build failure on linux-aarch64
Relates :  
JDK-8263548 - runtime/cds/appcds/SharedRegionAlignmentTest.java fails to compile after JDK-8263412
Relates :  
JDK-8331942 - On Linux aarch64, CDS archives should be using 64K alignment by default
Relates :  
JDK-8331952 - --enable-compatible-cds-alignment should be enabled by default
Relates :  
JDK-8231610 - Relocate the CDS archive if it cannot be mapped to the requested address
Relates :  
JDK-8230645 - CDS regions get loaded with the wrong alignment
Description
If you build JDK on a machime with 4k pages, and then move it to machine with 64k pages, java will not start (see below).

The problem goes away if you rebuild CDS archive. 

*This bug has signisficant impact to development process.*

Running a simple java -version results:

./jdk/bin/java -version

[0.015s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 4096 actual: 65536


openjdk version "14-internal" 

OpenJDK Runtime Environment (build 14-internal+0-adhoc.jenkins.jdk-dev-nightly)
Comments
Changeset: 3820ab9e Author: Yumin Qi <minqi@openjdk.org> Date: 2021-03-11 16:49:24 +0000 URL: https://git.openjdk.java.net/jdk/commit/3820ab9e
11-03-2021
Updated proposal: The bug 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 (note: you can run an x64 JDK on an M1-based MacBook using Rosetta) For example, 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 (#if defined(__APPLE__) || defined(AARCH64)), 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.
02-02-2021
The latest buildable and testable version can be found at: http://cr.openjdk.java.net/~minqi/jdk-8236847/jdk-8236847.patch
24-10-2020
Latest webrev as of 2020-02-13: http://cr.openjdk.java.net/~iklam/jdk15/8236847-SharedRegionAlignment.v03/
20-10-2020
JDK-8243392 will simplify the calculation of CDS region alignment. So this bug should be fixed after JDK-8243392
05-05-2020
Proposed fix: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-January/037888.html
29-01-2020
The JVM actually starts up normally (but CDS is disabled). However, the "error" message is misleading and may cause some test script to incorrectly conclude that execution has failed. The error can be simulated by changing this line in MetaspaceShared::map_archive(): - if (mapinfo->alignment() != (size_t)os::vm_allocation_granularity()) { + if (mapinfo->alignment() != (size_t)os::vm_allocation_granularity() || true) { $ java -version [0.038s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 4096 actual: 4096 java version "15-internal" 2020-09-15 Java(TM) SE Runtime Environment (slowdebug build 15-internal+0-adhoc.iklam.open) Java HotSpot(TM) 64-Bit Server VM (slowdebug build 15-internal+0-adhoc.iklam.open, mixed mode) $ java -cp ~/tmp HelloWorld [0.037s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 4096 actual: 4096 Hello World
11-01-2020
And the reverse is true as well. On aarch64 for example, this means that you can't run a JDK on Ubuntu if it was built on Red Hat, and vice versa. Could argue this is P1.
09-01-2020