hotspot Zero for iOS

David Alayachew davidalayachew at gmail.com
Sun Dec 15 21:13:26 UTC 2024


Wonderful, wonderful news.

I do not have an IOS device unfortunately, so I cannot test this, but
wonderful news all the same.

Thank you for your time and efforts on this. This is a huge milestone.

On Sun, Dec 15, 2024 at 3:18 PM Johan Vos <johan.vos at gluonhq.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/mobile-dev/attachments/20241215/b701bafa/attachment.htm>


More information about the mobile-dev mailing list