I'm doing some work here: https://github.com/tsayao/glass-wayland
So far it's been a good experience to use FFM / jextract. The idea is to plug it as a glass wayland backend when it's good enough. Em seg., 22 de abr. de 2024 às 16:16, Nir Lisker <nlis...@gmail.com> escreveu: > Not sure it helps with warmup, but marking a foreign function as critical > can improve performance: > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean) > . > > On Mon, Apr 22, 2024 at 10:02 PM Philip Race <philip.r...@oracle.com> > wrote: > >> No, it wasn't. I didn't even use jextracted code. >> The startup cost is around initialisation of FFM - around 70 ms (IIRC) >> overhead on my MacBook >> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I >> measured, so do these lazily if you can. >> And warmup cost is that it takes about 10000 iterations to get code fully >> compiled. >> >> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold >> intx CompileThreshold = >> 10000 {pd product} {default} >> double CompileThresholdScaling = >> 1.000000 {product} {default} >> uintx IncreaseFirstTierCompileThresholdAt = >> 50 {product} {default} >> intx Tier2CompileThreshold = >> 0 {product} {default} >> intx Tier3CompileThreshold = >> 2000 {product} {default} >> intx Tier4CompileThreshold = >> 15000 {product} {default} >> >> -phil. >> >> >> On 4/22/24 11:45 AM, Thiago Milczarek Sayão wrote: >> >> I think the startup time might be related to all static symbol lookups. >> So I'm manually including just what is needed: >> >> jextract --output src -t com.sun.glass.wayland.extracted \ >> --header-class-name GlassWayland \ >> `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \ >> `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \ >> glass-wayland.h \ >> --include-function xdp_portal_initable_new \ >> --include-function xdp_session_close \ >> --include-function xdp_portal_open_file \ >> --include-function xdp_portal_open_file_finish \ >> --include-function g_object_unref \ >> --include-function g_timeout_add \ >> --include-function g_add_idle \ >> --include-function g_main_loop_run \ >> --include-function g_main_loop_new \ >> --include-function g_main_loop_ref \ >> --include-function g_main_loop_unref \ >> --include-function g_main_loop_quit \ >> --include-function g_settings_new \ >> --include-function g_settings_get_int \ >> --include-function wl_display_connect \ >> --include-function wl_display_disconnect \ >> --include-function wl_display_roundtrip \ >> --include-function wl_display_dispatch_pending \ >> --include-typedef GAsyncReadyCallback \ >> --include-typedef GSourceFunc \ >> --include-typedef GError >> >> >> Em seg., 22 de abr. de 2024 às 13:24, Philip Race <philip.r...@oracle.com> >> escreveu: >> >>> As a reminder, using FFM will require all FX *applications* to specify >>> --enable-native-access on the command line >>> Although this is likely coming to JNI soon too. >>> >>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html >>> >>> But one thing to watch out for with FFM is startup + warm up time. >>> I struggled a lot with that in using FFM for just one library in the >>> java.desktop module. >>> >>> -phil >>> >>> On 4/22/24 9:12 AM, Nir Lisker wrote: >>> >>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the >>> N-1 rule. >>> >>> On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker <nlis...@gmail.com> wrote: >>> >>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did >>>> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's >>>> very useful for JavaFX, but was told we shouldn't since it's not an LTS >>>> version. >>>> >>>> I have no idea how long the work on Wayland will take including the >>>> code review (a rather long process), but you should be able to request code >>>> reviews with FFM and have it ready for integration by Java 25. >>>> >>>> On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão < >>>> thiago.sa...@gmail.com> wrote: >>>> >>>>> I was just experimenting, but it seems to be less work than going with >>>>> JNI. >>>>> If I am correct, the next Java LTS will be 25, which will be required >>>>> on JavaFX 29 to be released on September/29. >>>>> >>>>> It's 7 years - that's really too much. >>>>> >>>>> Maybe it's still worthwhile to prototype using FFM and then port >>>>> everything to JNI. >>>>> >>>>> -- Thiago. >>>>> >>>>> >>>>> Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth < >>>>> kevin.rushfo...@oracle.com> escreveu: >>>>> >>>>>> Note also that we cannot use Panama in the JavaFX internals yet, >>>>>> since >>>>>> the minimum version of the JDK is 21. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I did a small test app to explore Wayland client and portals (for >>>>>> > Robot and dialogs such as file open/save). >>>>>> > >>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c >>>>>> > >>>>>> > It seems it will work as a glass backend, but some walls will be >>>>>> hit >>>>>> > on the way :) >>>>>> > >>>>>> > I have tried to use jextract (from project Panama) to work directly >>>>>> > with java, but it seems it does not support wl_ types. >>>>>> > >>>>>> > -- Thiago. >>>>>> >>>>>> >>> >>
