hotspot Zero for iOS

Wed May 7 12:05:20 UTC 2025

Hi Johan,

On 7/05/2025 5:02 pm, Johan Vos wrote:
> 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.

Good to know. I know the old iOS port is long gone, but wasn't sure if 
the new/current port still needed it.

Thanks,
David

> - Johan
> 
> On Wed, May 7, 2025 at 8:37 AM Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com <mailto: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 <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 <https://
>>>     bugs.openjdk.org/browse/JDK-8346233>
>>>     [2] https://github.com/openjdk/mobile/commit/
>>>     ce70629f4394184ba517fb99c92ac9374ec8f37a <https://github.com/
>>>     openjdk/mobile/commit/ce70629f4394184ba517fb99c92ac9374ec8f37a>
>>>     [3] https://bugs.openjdk.org/browse/JDK-8339480 <https://
>>>     bugs.openjdk.org/browse/JDK-8339480>
> 