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.
>>>>>
>>>>>
>>
>
