hotspot Zero for iOS

[Johan Vos]

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/504aca60/attachment-0001.htm>