From david.holmes at oracle.com Wed May 7 00:48:33 2025 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 May 2025 10:48:33 +1000 Subject: hotspot Zero for iOS In-Reply-To: References: Message-ID: <18809b11-d5a1-459a-b40b-c4da2a6f74ff@oracle.com> 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. 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 From magnus.ihse.bursie at oracle.com Wed May 7 06:36:49 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 May 2025 08:36:49 +0200 Subject: hotspot Zero for iOS In-Reply-To: <18809b11-d5a1-459a-b40b-c4da2a6f74ff@oracle.com> References: <18809b11-d5a1-459a-b40b-c4da2a6f74ff@oracle.com> Message-ID: 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: From johan.vos at gluonhq.com Wed May 7 07:02:50 2025 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 7 May 2025 09:02:50 +0200 Subject: hotspot Zero for iOS In-Reply-To: References: <18809b11-d5a1-459a-b40b-c4da2a6f74ff@oracle.com> Message-ID: 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: From david.holmes at oracle.com Wed May 7 12:05:20 2025 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 May 2025 22:05:20 +1000 Subject: hotspot Zero for iOS In-Reply-To: References: <18809b11-d5a1-459a-b40b-c4da2a6f74ff@oracle.com> Message-ID: <6a8e06b3-8b60-4cfe-9be4-0099c1bc5463@oracle.com> 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 > > > 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 > 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 >> bugs.openjdk.org/browse/JDK-8346233> >>> [2] https://github.com/openjdk/mobile/commit/ >>> ce70629f4394184ba517fb99c92ac9374ec8f37a >> openjdk/mobile/commit/ce70629f4394184ba517fb99c92ac9374ec8f37a> >>> [3] https://bugs.openjdk.org/browse/JDK-8339480 >> bugs.openjdk.org/browse/JDK-8339480> >