<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 27/09/2023 10:59, tison wrote:<br>
</div>
<blockquote type="cite" cite="mid:CALL9TYJNdTjQqDhqgjvbinoxjXJ16pQFQQ6F__0RkOhDgOVOHg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif">OT
- perhaps I should start a new thread, but the first things
come to me when I talk to the FFM APIs:</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">1.
Manually defining MemoryLayout can be clumsy. C# has a
structure layout attribute for generating struct/class
marshalling[1]</div>
<div class="gmail_default" style="font-family:arial,sans-serif">2.
I wonder if the new FFI calls can be JIT-ed. One of the major
performance impact factor of JNI is that they treat the
foreign method as black box and nothing optimize can be done
=。=</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">These
are only rough ideas and I'm glad to know where I can start to
learn the related work and previous discussions.</div>
</div>
</blockquote>
<p>As Remi points out, our approach is to auto generate layouts and
ancillary data structures, with a tool called jextract:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/openjdk/jextract">https://github.com/openjdk/jextract</a></p>
<p>You can download the jextract version compatible with 21 here:</p>
<p><a class="moz-txt-link-freetext" href="https://jdk.java.net/">https://jdk.java.net/</a></p>
<p>The current state of the FFM API is captured in a talk I gave few
months ago, which could be a good starting point:</p>
<p><a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=kUFysMkMS00">https://www.youtube.com/watch?v=kUFysMkMS00</a><br>
</p>
<p>As to why we just didn't add a bunch of annotation... the answer
is longer. That's kind of where we started:</p>
<p><a class="moz-txt-link-freetext" href="https://cr.openjdk.org/~mcimadamore/panama/panama-binder-v3.html">https://cr.openjdk.org/~mcimadamore/panama/panama-binder-v3.html</a></p>
<p>But we quickly realized that this approach was not "primitive"
enough. E.g. trying to come up with an API to model C, while it
might be handy for casual native interop, doesn't scale in at
least two cases:</p>
<p>* clients that want to manipulate off-heap memory but don't care
about FFI (Netty, Lucene, ...)<br>
* clients that want to build on top of our FFI support and define
their own high-level interop stories (e.g. JNA, JNR, ...)</p>
<p>This realization is captured in this talk I gave few years ago:</p>
<p><a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=r4dNRVWYaZI">https://www.youtube.com/watch?v=r4dNRVWYaZI</a></p>
<p>There are of course a number of other technical reasons as to why
annotations are not a great primitive fit. For instance, you'd
need a reliable iteration order when scanning the methods of a
class reflectively, which Java does NOT provide. Secondly, having
to generate proxies on the fly for everything was particularly
problematic, especially for startup, and especially for allowing
Panama use from within the JDK itself.</p>
<p>The FFM API you see today sits at a lower level than e.g. what C#
provides. But the idea is that if a framework just wants
annotations and wrapper interfaces, they should be able to do just
that, and we shouldn't be in the way. This is, for example, what
JPassport does:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/boulder-on/JPassport">https://github.com/boulder-on/JPassport</a></p>
<p>As FFM exits finalization, I hope that other popular frameworks
such as JNA and JNR will switch from JNI to FFM, and deliver
better performance for their users (such frameworks have to
currently rely on libffi/JNI and, as a result, they can be slower
compared to plain JNI).</p>
<p>Note also that we're actively exploring solutions to make the
mapping between _records_ and struct layouts easier:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/openjdk/panama-foreign/pull/833">https://github.com/openjdk/panama-foreign/pull/833</a></p>
<p>That work is still in progress, and will not make it 22 (as we
are now focussing on finalizing the API), but it will appear at
some point.<br>
</p>
<p><br>
</p>
<p>On your question re. foreign call being treated as blackbox -
this is still the case in FFM - that is, FFM doesn't look into the
assembly of the target function to try and inline that code
elsewhere, or perform other optimizations. Such an approach seems
fragile, unless one assumes that the target function code is
available in some other form (e.g. LLVM bitcode). Otherwise, it's
a bit like trying to reconstruct source code information from
classfile bytecodes, which is one problem that project Babylon [1]
aims to address). That said, we don't rule out other targeted
optimizations (e.g. being able to elide some of the thread
transition from Java to native for back to back native calls has
long been on the agenda).</p>
<p>Cheers<br>
Maurizio</p>
<p>[1] -
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/discuss/2023-September/006226.html">https://mail.openjdk.org/pipermail/discuss/2023-September/006226.html</a><br>
</p>
<blockquote type="cite" cite="mid:CALL9TYJNdTjQqDhqgjvbinoxjXJ16pQFQQ6F__0RkOhDgOVOHg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><font face="arial, sans-serif">Best,</font></div>
<div><font face="arial, sans-serif">tison.</font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div>
<div class="gmail_default" style="font-family:arial,sans-serif">[1] <a href="https://learn.microsoft.com/en-us/dotnet/standard/native-interop/type-marshalling" moz-do-not-send="true" class="moz-txt-link-freetext">https://learn.microsoft.com/en-us/dotnet/standard/native-interop/type-marshalling</a></div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">tison <<a href="mailto:wander4096@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">wander4096@gmail.com</a>>
于2023年9月27日周三 17:53写道：<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif">Thanks for your quick
response and suggestions! I realize that using static
final MethodHandle and call invoke/invokeExact inside the
wrapper class should be better. While the downside is I
may have to duplicate some code like:</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">private static final
MethodHandle xxxNativeMethod = ...;</div>
<div class="gmail_default" style="font-family:arial,sans-serif">public static /*
native */ ReturnType xxx(T1 t1, T2 t2, ...) {</div>
<div class="gmail_default" style="font-family:arial,sans-serif"> // validate</div>
<div class="gmail_default" style="font-family:arial,sans-serif"> return
xxxNativeMethod.invoke(t1, t2, ...); // with return type
coercion and exception handling</div>
<div class="gmail_default" style="font-family:arial,sans-serif">}</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">I'll try to do it and
share it openly when I make an MVP.</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">FWIW, in the past
months, I built a Java binding for a Rust lib named
OpenDAL[1] using JNI since it requires JDK 8
compatibility. But this time I'd like to try out
Datafusion with the new FFM APIs for fun :D</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><font face="arial, sans-serif">Best,</font></div>
<div><font face="arial, sans-serif">tison.</font></div>
<div><font face="arial, sans-serif"><br>
</font></div>
<div><font face="arial, sans-serif">[<span class="gmail_default" style="font-family:arial,sans-serif">1] </span></font><a href="https://github.com/apache/incubator-opendal/tree/main/bindings/java" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/apache/incubator-opendal/tree/main/bindings/java</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
于2023年9月27日周三 17:43写道：<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Glavo's suggestion is correct. If you want the method
handle call to apply the maximum set of conversions,
you should use `invokeWithArguments`.</p>
<p>The price to pay is that, the further you move away
from `invokeExact` the slower the method call will go
(because of the conversion code than needs to surround
the code itself).</p>
<p>Also notice that, with your approach, the method
handle wrapping the function is not static final (it
is final, but not static). This means it is not a true
JVM constant. This means your method handle call will
probably not be inlined very well. Wrapping with a
record instead of a plain class might be better
because records fields are trusted. So if you wrap a
method handle in a NativeMethod _record_ and then you
stick the record instance in a static final field
somewhere, that _should_ work as expected (waving
hands furiously).<br>
</p>
<p>Anyway, of course all the above doesn't mean you
shouldn't do what you are trying to do - if
performance is not a concern for you then your
approach is totally reasonable.</p>
<p>Cheers<br>
Maurizio<br>
</p>
<div>On 27/09/2023 10:29, Glavo wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">See
MethodHandle::invokeWithArguments.</div>
<div dir="ltr"><br>
</div>
<div>Glavo</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 27,
2023 at 5:14 PM tison <<a href="mailto:wander4096@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">wander4096@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif">I'm using
OpenJDK 21 and prototyping FFM APIs.</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">Instead
of passing the MethodHandle returned
by linker.downcallHandle here and there, I'm
trying to wrap it into a NativeMethod class:</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">public
final class NativeMethod {<br>
private final String name;<br>
private final FunctionDescriptor
descriptor;<br>
private final MethodHandle handle;<br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">
public Object invoke(Object... args) throws
Throwable {<br>
return this.handle.invoke(args);<br>
}<br>
}<br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">But it
seems the varargs pass through is not quit
fluent:</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">java.lang.invoke.WrongMethodTypeException:
cannot convert MethodHandle(int)int to
(Object[])Object<br>
<br>
at
java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:903)<br>
at
java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:870)<br>
at
java.base/java.lang.invoke.Invokers.checkGenericType(Invokers.java:541)<br>
at
io.montumi.datafusion.core.NativeMethod.invoke(NativeMethod.java:22)<br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">While if
I public the handle and call invoke from the
handle directly, all the behavior is expected.</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><font face="arial,
sans-serif">Best,</font></div>
<div><font face="arial,
sans-serif">tison.</font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>