JDK-8262895 : [macos_aarch64] runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-03-02
  • Updated: 2024-08-27
  • Resolved: 2023-02-27
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 21
21 b12Fixed
Related Reports
Relates :  
JDK-8258576 - Try to get zerobased CCS if heap is above 32 and CDS is disabled
Relates :  
JDK-8234058 - runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr
Relates :  
JDK-8258756 - AArch64: can't get compressed class pointers with unscaled encoding.
Description
Testing https://github.com/openjdk/jdk/pull/2200 reveals this failure in runtime/CompressedOops/CompressedClassPointers.java:

 stdout: [[0.011s][info][gc,metaspace] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824
[0.011s][info][gc,metaspace] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000
];
 stderr: [Java HotSpot(TM) 64-Bit Server VM warning: Shared spaces are not supported in this VM
java version "17-internal" 2021-09-14 LTS
Java(TM) SE Runtime Environment (fastdebug build 17-internal+0-LTS-2021-02-27-1954067.mikael.vidstedt.jdk-macosjib)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 17-internal+0-LTS-2021-02-27-1954067.mikael.vidstedt.jdk-macosjib, mixed mode)
]
 exitValue = 0

java.lang.RuntimeException: 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:206)
	at CompressedClassPointers.largeHeapAbove32GTest(CompressedClassPointers.java:128)
	at CompressedClassPointers.main(CompressedClassPointers.java:324)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2825 Date: 2024-08-27 00:11:42 +0000
27-08-2024
Changeset: f5a12768 Author: Matias Saavedra Silva <matsaave@openjdk.org> Committer: Coleen Phillimore <coleenp@openjdk.org> Date: 2023-02-27 15:53:33 +0000 URL: https://git.openjdk.org/jdk/commit/f5a12768fba4a6508fb0359aedd608fd9d6d9024
27-02-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/12234 Date: 2023-01-26 20:34:32 +0000
27-01-2023
The test seems unreliable on macOS in general, regardless of the underlaying hardware architecture, i.e. x86_64 or aarch64 Not sure how useful it is on macOS because of that, but also in a big picture kind of way, why do we have such test in the first place. Thomas Stuffe said this in his review of a related issue https://github.com/openjdk/jdk/pull/3865#discussion_r630171134: "Arguably we may even completely exclude the test, like I do for AIX already. Its important for Windows, somewhat less important for Linux, and covers other platforms only for completeness sake." So the question is: is it the case here as well that the test is of a less significance on macOS compared to Linux/Windows? Moving out of JDK17.
08-06-2021
I get the same failure even on x86_64 mac (after running many processes for a while). Rebooting the machine makes it work for an undermined period of time, till the OS VM space gets fragmented enough (?) again.
04-06-2021
For the bookkeeping, the change https://github.com/openjdk/jdk/pull/2200/commits/d1783762d9a9b29e9fdf6784a911d6dfb31b0479
12-03-2021
Thanks for analysis Richard, we will disable the subtest on mac_aarch64 for now
09-03-2021
There seems to be an issue with mapping the heap at preferred addresses[1] on macos_aarch64. With additional tracing and setting -XX:HeapSearchSteps=40 we see that the vm fails to map the heap at one of the preferred addresses (thanks Vladimir for doing the test): images/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001800000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000002000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000004000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000005000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008000000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0018000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0020000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0080000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0100000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0110000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address NULL heap of size 0x7c1000000 [0.006s][debug][gc,heap,coops] Protected page at the reserved heap base: 0x0000000280000000 / 16777216 bytes [0.006s][debug][gc,heap,coops] Heap address: 0x0000000281000000, size: 31744 MB, Compressed Oops mode: Non-zero based: 0x0000000280000000, Oop shift amount: 3 [0.007s][info ][gc,metaspace ] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824 [0.007s][info ][gc,metaspace ] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000 openjdk version "17-internal" 2021-09-14 OpenJDK Runtime Environment (build 17-internal+0-adhoc.tester.jdk) OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc.tester.jdk, mixed mode) [0,044s][info ][gc,heap,exit ] Heap [0,044s][info ][gc,heap,exit ] garbage-first heap total 262144K, used 1647K [0x0000000281000000, 0x0000000a41000000) [0,044s][info ][gc,heap,exit ] region size 16384K, 1 young (16384K), 0 survivors (0K) [0,044s][info ][gc,heap,exit ] Metaspace used 3401K, committed 3456K, reserved 1056768K [0,044s][info ][gc,heap,exit ] class space used 267K, committed 320K, reserved 1048576K Finally it is mapped at 10GB (0x0000000281000000), leaving hardly room for a 4GB aligned[2] compressed class space below 32G. And indeed we get a compressed class space with an encoding base that is not zero and largeHeapAbove32GTest fails then. [1] get_attach_addresses_for_disjoint_mode(): https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477 [2] On aarch64 the encoding base has to be 4GB aligned. Unfortunately the 4GB alignment is enforced to strictly on the start address of the compressed class space instead of enforcing it on the encoding base. See JDK-8258756.
05-03-2021
so it fails only in one subtest , rest of subtests are working fine at CompressedClassPointers.largeHeapAbove32GTest(CompressedClassPointers.java:128) this subtest was added as part of JDK-8258576 just recently
04-03-2021
That test should probably be disabled on mac_aarch64 same way it was disabled on windows ( https://bugs.openjdk.java.net/browse/JDK-8234058 ) due to ASLR
03-03-2021