Using Java on macOS ARM64

[Stephan Bergmann]

On 18/12/2020 11:59, Stephan Bergmann wrote:
> * 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.

At least with the recent
<https://cdn.azul.com/zulu/bin/zulu17.0.63-ea-jdk17.0.0-ea.27-macosx_aarch64.zip>
on macOS 11.4, things finally appear to reliably work for me (see 
<https://git.libreoffice.org/core/+/e529461bcb126e0975ffa3f86e1fd5a630551de2%5E%21> 
"Enable JVM also on macOS ARM64")