hotspot Zero for iOS

[Johan Vos]

Hi,

Good question -- thanks David for asking this here before removing it in
mainline.
As Magnus said, there is no place anymore where USE_LIBRARY_BASED_TLS_ONLY
is set, so it is currently not used on iOS and its removal won't have
impact on the mobile repository.
At the very least, there are no compile-time issues -- I'll investigate how
this is handled, but no problem at all to remove the
USE_LIBRARY_BASED_TLS_ONLY definition.

- Johan

On Wed, May 7, 2025 at 8:37 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2025-05-07 02:48, David Holmes wrote:
>
> 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.
>
> That code seems defunct anyway, the essential part:
>
>  #if TARGET_OS_IPHONE #define USE_LIBRARY_BASED_TLS_ONLY
>
>
> in globalDefinitions_gcc.hpp being long gone, so
> USE_LIBRARY_BASED_TLS_ONLY is never defined.
>
> /Magnus
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/mobile-dev/attachments/20250507/8a8f264d/attachment.htm>