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.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
