Closed kgibm closed 10 months ago
Does it work with a 0.41 build?
The Semeru Milestone 2 builds: https://github.com/ibmruntimes/semeru11-binaries/releases/tag/jdk-11.0.21%2B8_openj9-0.41.0-m2
or the latest build (this is an OpenJ9 build and not Semeru): https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK11_aarch64_mac_Release/73/OpenJ9-JDK11-aarch64_mac-20231018-142016.tar.gz from https://openj9-jenkins.osuosl.org/job/Build_JDK11_aarch64_mac_Release/73/
This version of Eclipse requires Java 17 so those won't work but I found the latest OpenJ9 17 build from https://openj9-jenkins.osuosl.org/job/Build_JDK17_aarch64_mac_Release/ but I get similar strange and changing errors (note that the Secure coding is not enabled for restorable state
warning seems to be benign as it is also seen with Adoptium); for examples:
$ java -version
openjdk version "17.0.9-internal" 2023-10-17
OpenJDK Runtime Environment (build 17.0.9-internal+0-adhoc.jenkins.BuildJDK17aarch64macRelease)
Eclipse OpenJ9 VM (build v0.41.0-release-9c5799b80a6, JRE 17 Mac OS X aarch64-64-Bit 20231019_67 (JIT enabled, AOT enabled)
OpenJ9 - 9c5799b80a6
OMR - fa7b6ddc7a5
JCL - 83ba13c3976 based on jdk-17.0.9+9)
$ ../org.eclipse.mat.product/target/products/org.eclipse.mat.ui.rcp.MemoryAnalyzer/macosx/cocoa/aarch64/MemoryAnalyzer.app/Contents/MacOS/MemoryAnalyzer
2023-10-23 14:56:25.783 MemoryAnalyzer[47202:2138705] WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.
java.lang.IllegalStateException: Error initializing storage for Equinox container.
at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:110)
at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:53)
at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:46)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:315)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:251)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:651)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:588)
at org.eclipse.equinox.launcher.Main.run(Main.java:1459)
Caused by: java.lang.NullPointerException
at java.base/java.util.HashMap.resize(HashMap.java:733)
at java.base/java.util.HashMap.putVal(HashMap.java:661)
at java.base/java.util.HashMap.put(HashMap.java:610)
at org.eclipse.osgi.container.ModuleResolutionReport$Builder.addEntry(ModuleResolutionReport.java:52)
at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.filterResolvable(ModuleResolver.java:1317)
at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:878)
at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:176)
at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:553)
at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:503)
at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:1144)
at org.eclipse.osgi.storage.Storage.checkSystemBundle(Storage.java:436)
at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:187)
at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:108)
... 11 more
$ ../org.eclipse.mat.product/target/products/org.eclipse.mat.ui.rcp.MemoryAnalyzer/macosx/cocoa/aarch64/MemoryAnalyzer.app/Contents/MacOS/MemoryAnalyzer
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/java.lang.J9VMInternals.ensureError(J9VMInternals.java:206)
at java.base/java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:195)
at java.base/sun.security.util.DisabledAlgorithmConstraints$Constraints.<init>(DisabledAlgorithmConstraints.java:371)
at java.base/sun.security.util.DisabledAlgorithmConstraints.<init>(DisabledAlgorithmConstraints.java:150)
at java.base/sun.security.util.DisabledAlgorithmConstraints.<init>(DisabledAlgorithmConstraints.java:124)
at java.base/sun.security.util.DisabledAlgorithmConstraints$JarHolder.<clinit>(DisabledAlgorithmConstraints.java:100)
at java.base/sun.security.util.DisabledAlgorithmConstraints.jarConstraints(DisabledAlgorithmConstraints.java:114)
at java.base/sun.security.pkcs.SignerInfo.<clinit>(SignerInfo.java:61)
at java.base/sun.security.pkcs.PKCS7.parseSignedData(PKCS7.java:364)
at java.base/sun.security.pkcs.PKCS7.parse(PKCS7.java:158)
at java.base/sun.security.pkcs.PKCS7.parse(PKCS7.java:126)
at java.base/sun.security.pkcs.PKCS7.<init>(PKCS7.java:108)
at java.base/sun.security.util.SignatureFileVerifier.<init>(SignatureFileVerifier.java:125)
at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:308)
at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:761)
at java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1035)
at java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72)
at java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:1015)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:1160)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:961)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:867)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:825)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1095)
Caused by: java.lang.NumberFormatException: For input string: "AEE4BDD" under radix 16
at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
at java.base/java.lang.Integer.parseInt(Integer.java:672)
at java.base/java.math.BigInteger.<init>(BigInteger.java:547)
at java.base/sun.security.util.CurveDB.bi(CurveDB.java:109)
at java.base/sun.security.util.CurveDB.add(CurveDB.java:125)
at java.base/sun.security.util.CurveDB.<clinit>(CurveDB.java:705)
... 23 more
Can you pls try with -Xint to help narrow it down. You could set the environment variable OPENJ9_JAVA_OPTIONS=-Xint
.
Nice! -Xint
works as a workaround.
@hzongaro @knn-k fyi
I was able to reproduce the failure on my laptop. Looking at the system dump taken on NullPointerException occurrences, I found that a NullPointerException was thrown because the value of x18 register was zero. It was fine to use x18 in the application code on older macOS and AArch64 JIT compiler treats x18 as a normal, non-reserved register, but it seems that things have changed on macOS 13. https://stackoverflow.com/questions/71152539/consequence-of-violating-macoss-arm64-calling-convention
macOS 13 did indeed change this! While macOS 11 and 12 would unconditionally preserve x18, macOS 13 now has more complicated rules. x18 is now only preserved for processes running under Rosetta as well as processes that were either built against a macOS 12 SDK or older, or hold the com.apple.private.uexc or com.apple.private.custom-x18-abientitlements.
The same rules apply to iOS 16, with the caveats that there is no Rosetta and you cannot run binaries built against the macOS SDK. So as of iOS 16, x18 has to be considered off-limits again for all devices.
@knn-k is working on updating AArch64 JIT so that x18 is not touched on macOS.
@kgibm what OS version is your machine?
what OS version is your machine?
$ system_profiler SPSoftwareDataType SPHardwareDataType | grep -v -e UUID -e UDID -e 'User Name' -e 'Computer Name' -e Serial
Software:
System Software Overview:
System Version: macOS 14.0 (23A344)
Kernel Version: Darwin 23.0.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Secure Virtual Memory: Enabled
System Integrity Protection: Disabled
Time since boot: 11 days, 1 hour, 14 minutes
Hardware:
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: Mac14,10
Model Number: Z1740017JLL/A
Chip: Apple M2 Pro
Total Number of Cores: 12 (8 performance and 4 efficiency)
Memory: 32 GB
System Firmware Version: 10151.1.1
OS Loader Version: 10151.1.1
Activation Lock Status: Disabled
@kgibm Could you try a nightly build https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK17_aarch64_mac_Nightly/434/OpenJ9-JDK17-aarch64_mac-20231028-115225.tar.gz at https://openj9-jenkins.osuosl.org/job/Build_JDK17_aarch64_mac_Nightly/434/, please? It contains the fix #18351.
@knn-k Confirmed issue is fixed, thanks!
Java -version output
Summary of problem
Recent builds of packaged Eclipse fail to launch with Semeru but succeed with Adoptium on macOS ARM (works fine on Windows):
git clone https://git.eclipse.org/r/mat/org.eclipse.mat.git
cd org.eclipse.mat/parent
PATH
andJAVA_HOME
PATH
mvn -DskipTests=true -Dmat-target=mat-2023-12i -Dmat-product=mat-2023-12 clean install
../org.eclipse.mat.product/target/products/org.eclipse.mat.ui.rcp.MemoryAnalyzer/macosx/cocoa/aarch64/MemoryAnalyzer.app/Contents/MacOS/MemoryAnalyzer
Launching the same executable with Adoptium 17 works.
Re-building without targeting the latest Eclipse (i.e. by removing
-Dmat-target=mat-2023-12i -Dmat-product=mat-2023-12
from step 5) works fine with IBM Semeru Runtimes.Diagnostic files
Lots of different symptoms every time I try to launch. Examples: