hotspot Zero for iOS

[David Holmes]

Hi Johan,

Do the compilers for the mobile builds support direct use of thread 
local storage these days? Way back in 2016 in the old mobile project we 
had to set USE_LIBRARY_BASED_TLS_ONLY [1].

The question has been asked as to whether we can remove the 
USE_LIBRARY_BASED_TLS_ONLY code in mainline.

Thanks,
David Holmes


[1] https://mail.openjdk.org/pipermail/mobile-dev/2016-January/000067.html

On 16/12/2024 6:17 am, Johan Vos wrote:
> Hi,
>
> With JDK-8346233 [1] being fixed in the openjdk/mobile repo [2], the 
> mobile repo can now build a static version of the jvm (libjvm.a) that 
> works on iOS. This VM implementation is using the Zero interpreter, 
> which means that it is not using runtime-generated assembly code, and 
> it does not violate iOS rules (e.g. no w+x sections).
> The iOS sdk build can be created using
> `make static-libs-image`
> and it builds on top of the latest work in openjdk/jdk that 
> streamlines the build of static libraries and executables (e.g. see 
> JDK-8339480 [3])
>
> Using this in iOS apps requires the iOS app to include the libjvm.a as 
> well as the required native classlibs (e.g. libjava.a, libnet.a, ...) 
> Also, the required classes need to be available so that the 
> interpreter can use them. I will update the OpenJDK-mobile Wiki with 
> an example on how this can be done.
>
> For those wondering about the difference with what we previously did 
> at Gluon with mobile Java: in the past, we were using AOT compilers 
> that were linked to their own JVM implementation (e.g. RoboVM or 
> GraalVM Substrate). Those solutions showed that Java (and JavaFX) 
> really works on iOS and Android devices, and especially the GraalVM 
> AOT allowed for a really fast execution. However, those solutions were 
> not using the hotspot code in OpenJDK.
>
> With the recent changes, we are now re-enabling the original 
> architecture in the Mobile Project, by using the very latest hotspot 
> code (Zero interpreter) which aligns the project much closer to the 
> upstream OpenJDK. Over the past years, there have been tremendous 
> improvements in both the JVM and the JDK code in OpenJDK, and the fact 
> that we can use this great work to build apps on mobile is a huge 
> opportunity.
>
> Using the Zero interpreter allows us to prove that things work, and it 
> might eventually lead to passing the TCK. It won't give us 
> top-performance, which will be needed for mobile applications. That 
> means there is still lots of work to do in a number of areas, including
> * AOT: compiled methods (ahead of time, not at runtime) will generally 
> run much faster than interpreted methods. I hope that we can leverage 
> experience from GraalVM and Project Leyden.
> * footprint: we should only bundle code that is really required by a 
> specific app.
>
> Also, we need a similar build for Android -- although we can use a JIT 
> there, so we are not limited to Zero.
>
> Ultimately, this project will allow existing and new Java libraries 
> and projects to be used on mobile devices. This brings Java back in 
> pole-position for the Write Once Run Anywhere paradigm. This can even 
> be combined with OpenJFX, to have a single codebase for a complete 
> application including a modern UI, all written in Java, and running on 
> different client devices.
>
> As I said, there is lots of work to be done, but at least there is 
> Innovation Everywhere.
>
> - Johan
>
> [1] https://bugs.openjdk.org/browse/JDK-8346233
> [2] 
> https://github.com/openjdk/mobile/commit/ce70629f4394184ba517fb99c92ac9374ec8f37a
> [3] https://bugs.openjdk.org/browse/JDK-8339480