hotspot Zero for iOS

[Magnus Ihse Bursie]

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