Feedback / query on jextract for Windows 10

[Duncan Gittins]

Thanks for the information.  As you suspected that bug must be related 
and there is a minor difference in the --source output because the 
problem does go away when removing the jextract "--source" flag and 
making jar directly from generated classes rather than just compiling 
from the generated source code.

My code samples using jextract bindings are ~300ms slower at startup 
time (but same speed runtime). I'm not certain if this overhead is down 
to initialisation of static constants or simply to be expected when 
adding 11MB jar footprint (compared to 56k jar for my handwritten MH 
bindings). I will follow-up if I find out more.

Looking at the generated code for "xxx$constants$nn.java" there seems to 
be a degree of unnecessary initialisation per xxx$constants$nn class as 
it contains static variables for FunctionDescriptor / MemoryLayout which 
would be initialised every time that particular class was loaded and not 
used in my code. I felt that my own jar was slow starting so switched 
foreign linker references to a lazy load Supplier for every library / 
symbol / mh / vh so that only the referenced types get created.

I will have a look at future builds - this project is extremely useful 
so I hope it gets into a full JDK release soon. Unfortunately my issue 
with a huge jar in Eclipse means I can't easily develop using the 
generated code variant right now, but in the meantime the jextract code 
is still very helpful to work out how to call Windows APIs correctly.

Duncan

On 25/01/2021 10:20, Maurizio Cimadamore wrote:
>
> On 23/01/2021 18:34, Duncan Gittins wrote:
>> I've been using Panama on Windows 10 to eliminate my C# apps which I 
>> would normally call via ProcessBuilder. I'm very impressed so far and 
>> looking forward to newer versions: everything I have written in 
>> Windows C# is now replaced with foreign memory / linker calls to 
>> native code using the latest Java 16 EA.  I have examples for various 
>> Win32 API and COM objects, HWND objects and screensaver. However I'm 
>> struggling to get the code running with output from jextract build. 
>> Perhaps I overlooked something very obvious in how to setup?
>>
>> One example app is attached - this calls SystemParametersInfoA to set 
>> the Windows desktop background. There are two implementations of 
>> setImage: one with hardwired MethodHandle works fine, but the 
>> jextract version gives UnsupportedOperationException for layout 
>> unrelated to SystemParametersInfoA. If I edit the generated code to 
>> comment out all lines unrelated to SystemParametersInfoA then both 
>> versions of setImage work.
>
> I think the culprit is this:
>
> ```
> Caused by: java.lang.UnsupportedOperationException: Invalid alignment 
> requirements for layout 
> b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer]
>         at 
> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273)
>         at 
> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159)
>         at 
> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488)
>         at 
> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534)
>         at 
> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488)
>         at 
> duncan.win32.shobjidl_core.shlobj_core_h$constants$16.<clinit>(shlobj_core_h$constants$16.java:1844)
> ```
>
> This seems a duplicate of another issue that has been reported last week:
>
> https://bugs.openjdk.java.net/browse/JDK-8259832
>
> E.g. jextract ignoring alignment requirements. Note that jextract 
> generates lots of constants, and it takes only one bad one to make 
> initialization fail.
>
>>
>> The jextract command on Windows 10 (with fresh Vis Studio 
>> installation) expands shlobj_core.h because I my app also uses 
>> IShellLink.
>>
>>      set "WINKIT=c:\Program Files (x86)\Windows 
>> Kits\10\Include\10.0.18362.0"
>>      jextract --source -t duncan.win32.shobjidl_core -d 
>> shlobj_core.h/java     "%WINKIT%/um/shlobj_core.h"
>>
>> Another issue is that this single windows header file gives rise to 
>> 11MB jar and is unusable inside Eclipse (on my slow PC), and is slow 
>> startup at runtime. Have you considered changing the generated code 
>> to use lazy Supplier<MethodHandle> instead of MethodHandle to ensure 
>> only required handles are created on-demand?
>
> Uhm... we are already using dynamic constants, so you should only pay 
> for the MHs and VHs you use - e.g. in fact I'm even surprised you get 
> the failure inside the <clinit> above - since that constant should not 
> be initialized unless it's used. I wonder if there's a regression 
> here... are you using the `--source` flag? With that flag we revert 
> back to a monolithic header, so that will explain both failures. If 
> so, try removing that flag - and see what happens (if everything is 
> working as it should I don't think you should even see the error 
> above, assuming you never use that layout).
>
> Maurizio
>
>>
>> Kind regards
>>
>> Duncan
>>
>>