Using Java on macOS ARM64

Fri Dec 18 10:59:32 UTC 2020

To document my findings so far:

* Running a x86-64 LO with an x86-64 JDK works fine on ARM64.

* Running an ARM64 LO with an x86-64 JDK, LO can find the JDK but cannot 
instantiate an in-process JVM:

> warn:sal.osl:86417:2142204:sal/osl/unx/module.cxx:162: dlopen(/Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home/lib/server/libjvm.dylib, 9): dlopen(/Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home/lib/server/libjvm.dylib, 9): no suitable image found.  Did find:
> 	/Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home/lib/server/libjvm.dylib: mach-o, but wrong architecture
> 	/Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home/lib/server/libjvm.dylib: mach-o, but wrong architecture
> warn:jfw:86417:2142204:jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx:662: [Java framework]sunjavaplugin.dylib could not load Java runtime library: 
> file:///Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home/lib/server/libjvm.dylib

and LO's "...The selected JRE is defective..." error box.

* A macOS ARM64 JDK is work in progress 
(<https://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port"), and 
e.g. a MacPorts build of openjdk15 would still only cross-build an 
x86-64 one.  But Azul appears to be progressing that JEP 
(<https://adtmag.com/articles/2020/11/12/azul-supports-apple-silicon.aspx>), 
and already offers e.g. JDK13 
(<https://cdn.azul.com/zulu/bin/zulu13.35.1017-ca-jdk13.0.5.1-macos_aarch64.tar.gz>) 
and a JDK16EA 
(<https://cdn.azul.com/zulu/bin/zulu16.0.73-ea-jdk16.0.0-ea.28-macos_aarch64.zip>; 
curiously, there's no JDK15, though):

* The Azul JDK13 works, but after starting an in-process JVM in LO it 
crashes with a SIGBUS at

> Process 86470 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGBUS
>     frame #0: 0x000000016bdf41d8
> ->  0x16bdf41d8: mov    x9, #0x0
>     0x16bdf41dc: movk   x9, #0x0, lsl #16
>     0x16bdf41e0: mov    x10, #0x0
>     0x16bdf41e4: movk   x10, #0x0, lsl #16
> Target 0: (soffice) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGBUS
>   * frame #0: 0x000000016bdf41d8
>     frame #1: 0x0000000284fb7500 libjavaloaderlo.dylib`com::sun::star::uno::BaseReference::iquery_throw(pInterface=0x0000000287ea59d8, rType=0x0000000287ea20a0) at Reference.hxx:76:29
>     frame #2: 0x0000000284fb8ba4 libjavaloaderlo.dylib`com::sun::star::uno::Reference<com::sun::star::lang::XInitialization>::iquery_throw(pInterface=0x0000000287ea59d8) at Reference.hxx:88:12
>     frame #3: 0x0000000284fb8b60 libjavaloaderlo.dylib`com::sun::star::uno::Reference<com::sun::star::lang::XInitialization>::Reference(this=0x000000016fdfa6c0, rRef=0x0000000282591550, (null)=UNO_QUERY_THROW) at Reference.hxx:191:19
>     frame #4: 0x0000000284fb7108 libjavaloaderlo.dylib`com::sun::star::uno::Reference<com::sun::star::lang::XInitialization>::Reference(this=0x000000016fdfa6c0, rRef=0x0000000282591550, (null)=UNO_QUERY_THROW) at Reference.hxx:190:1
>     frame #5: 0x0000000284fb5ffc libjavaloaderlo.dylib`stoc_javaloader::(anonymous namespace)::JavaComponentLoader::getJavaLoader(this=0x0000000282591510) at javaloader.cxx:248:46
>     frame #6: 0x0000000284fb09a0 libjavaloaderlo.dylib`stoc_javaloader::(anonymous namespace)::JavaComponentLoader::activate(this=0x0000000282591510, rImplName=0x00000001157129e8, blabla=0x000000016fdfad78, rLibName=0x000000016fdfae08, xKey=0x000000016fdfad70) at javaloader.cxx:317:65
>     frame #7: 0x000000010124a5d8 libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::loadImplementation(this=0x000000011572a170, context=0x000000011572a210, implementation=std::__1::shared_ptr<cppuhelper::ServiceManager::Data::Implementation>::element_type @ 0x00000001157129e8 strong=3 weak=1) at servicemanager.cxx:849:22
>     frame #8: 0x000000010124e0cc libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::findServiceImplementation(this=0x000000011572a170, context=0x000000011572a210, specifier=0x000000016fdfbc58) at servicemanager.cxx:1793:9
>     frame #9: 0x000000010124daa0 libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::createInstanceWithContext(this=0x000000011572a170, aServiceSpecifier=0x000000016fdfbc58, Context=0x000000011572a210) at servicemanager.cxx:1000:9
>     frame #10: 0x000000010124d5b4 libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::createInstance(this=0x000000011572a170, aServiceSpecifier=0x000000016fdfbc58) at servicemanager.cxx:966:12
>     frame #11: 0x00000001021b5ca0 libfwklo.dylib`framework::DispatchProvider::implts_searchProtocolHandler(this=0x00000001777655e0, aURL=0x000000016fdfc6d0) at dispatchprovider.cxx:447:25
>     frame #12: 0x00000001021b4ca4 libfwklo.dylib`framework::DispatchProvider::implts_queryFrameDispatch(this=0x00000001777655e0, xFrame=0x000000016fdfc180, aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8, nSearchFlags=0) at dispatchprovider.cxx:355:27
>     frame #13: 0x00000001021b39fc libfwklo.dylib`framework::DispatchProvider::queryDispatch(this=0x00000001777655e0, aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8, nSearchFlags=0) at dispatchprovider.cxx:103:23
>     frame #14: 0x00000001021b9cb4 libfwklo.dylib`framework::InterceptionHelper::queryDispatch(this=0x0000000177768fc0, aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8, nSearchFlags=0) at interceptionhelper.cxx:81:33
>     frame #15: 0x000000010234e888 libfwklo.dylib`(anonymous namespace)::XFrameImpl::queryDispatch(this=0x0000000177765340, aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8, nSearchFlags=0) at frame.cxx:2338:22
[...]

That's apparently our JIT'ed vtable trampoline code (cf. 
generateCodeSnippet in 
bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx), and the SIGBUS 
smells like a write-vs.-execute issue with pthread_jit_write_protect_np 
(<https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon>), 
as issued both by us (cf. JitMemoryProtectionGuard in 
bridges/source/cpp_uno/shared/vtablefactory.cxx) and by the JVM (as seen 
with an lldb breakpoint).  Before instantiating the JVM, our 
pthread_jit_write_protect_np calls appear to work as intended, and such 
JIT'ed vtable trampoline code gets executed.  Maybe there's some issue 
in the JVM of not pairing calls properly, but I haven't found out 
anything for now.

* I didn't manage to get the Azul JDK16EA past the macOS "'zulu-16.jdk' 
is damaged and can't be opened." alert.