<div dir="ltr">Hi,<div><br></div><div>Good question -- thanks David for asking this here before removing it in mainline.</div><div>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.</div><div>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.</div><div><br></div><div>- Johan</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 7, 2025 at 8:37 AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">magnus.ihse.bursie@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>On 2025-05-07 02:48, David Holmes wrote:</p>
<blockquote type="cite">Hi
Johan,
<br>
<br>
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].
<br>
<br>
The question has been asked as to whether we can remove the
USE_LIBRARY_BASED_TLS_ONLY code in mainline.
<br>
</blockquote>
<p>That code seems defunct anyway, the essential part:<br>
</p>
<pre> #if TARGET_OS_IPHONE
<span> #define USE_LIBRARY_BASED_TLS_ONLY
</span></pre>
<p></p>
<p>in globalDefinitions_gcc.hpp being long gone, so
USE_LIBRARY_BASED_TLS_ONLY is never defined.</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite">Thanks,
<br>
David Holmes
<br>
<br>
<br>
[1]
<a href="https://mail.openjdk.org/pipermail/mobile-dev/2016-January/000067.html" target="_blank">https://mail.openjdk.org/pipermail/mobile-dev/2016-January/000067.html</a>
<br>
<br>
On 16/12/2024 6:17 am, Johan Vos wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
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).
<br>
The iOS sdk build can be created using
<br>
`make static-libs-image`
<br>
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])
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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
<br>
* 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.
<br>
* footprint: we should only bundle code that is really required
by a specific app.
<br>
<br>
Also, we need a similar build for Android -- although we can use
a JIT there, so we are not limited to Zero.
<br>
<br>
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.
<br>
<br>
As I said, there is lots of work to be done, but at least there
is Innovation Everywhere.
<br>
<br>
- Johan
<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8346233" target="_blank">https://bugs.openjdk.org/browse/JDK-8346233</a>
<br>
[2]
<a href="https://github.com/openjdk/mobile/commit/ce70629f4394184ba517fb99c92ac9374ec8f37a" target="_blank">https://github.com/openjdk/mobile/commit/ce70629f4394184ba517fb99c92ac9374ec8f37a</a><br>
[3] <a href="https://bugs.openjdk.org/browse/JDK-8339480" target="_blank">https://bugs.openjdk.org/browse/JDK-8339480</a>
<br>
</blockquote>
</blockquote>
</div>
</blockquote></div>