Wayland

[Philip Race]

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.race at 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 <nlisker at 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.sayao at 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.rushforth at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/348abe8d/attachment.htm>