How to wrap Method handle behind a class?
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Sep 27 11:34:30 UTC 2023
On 27/09/2023 10:59, tison wrote:
> OT - perhaps I should start a new thread, but the first things come to
> me when I talk to the FFM APIs:
>
> 1. Manually defining MemoryLayout can be clumsy. C# has a structure
> layout attribute for generating struct/class marshalling[1]
> 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 =。=
>
> These are only rough ideas and I'm glad to know where I can start to
> learn the related work and previous discussions.
As Remi points out, our approach is to auto generate layouts and
ancillary data structures, with a tool called jextract:
https://github.com/openjdk/jextract
You can download the jextract version compatible with 21 here:
https://jdk.java.net/
The current state of the FFM API is captured in a talk I gave few months
ago, which could be a good starting point:
https://www.youtube.com/watch?v=kUFysMkMS00
As to why we just didn't add a bunch of annotation... the answer is
longer. That's kind of where we started:
https://cr.openjdk.org/~mcimadamore/panama/panama-binder-v3.html
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:
* clients that want to manipulate off-heap memory but don't care about
FFI (Netty, Lucene, ...)
* clients that want to build on top of our FFI support and define their
own high-level interop stories (e.g. JNA, JNR, ...)
This realization is captured in this talk I gave few years ago:
https://www.youtube.com/watch?v=r4dNRVWYaZI
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.
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:
https://github.com/boulder-on/JPassport
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).
Note also that we're actively exploring solutions to make the mapping
between _records_ and struct layouts easier:
https://github.com/openjdk/panama-foreign/pull/833
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.
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).
Cheers
Maurizio
[1] - https://mail.openjdk.org/pipermail/discuss/2023-September/006226.html
>
> Best,
> tison.
>
> [1]
> https://learn.microsoft.com/en-us/dotnet/standard/native-interop/type-marshalling
>
>
> tison <wander4096 at gmail.com> 于2023年9月27日周三 17:53写道：
>
> 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:
>
> private static final MethodHandle xxxNativeMethod = ...;
> public static /* native */ ReturnType xxx(T1 t1, T2 t2, ...) {
> // validate
> return xxxNativeMethod.invoke(t1, t2, ...); // with return
> type coercion and exception handling
> }
>
> I'll try to do it and share it openly when I make an MVP.
>
> 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
>
> Best,
> tison.
>
> [1]
> https://github.com/apache/incubator-opendal/tree/main/bindings/java
>
>
> Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> 于2023年9月27日周三 17:43写道：
>
> Glavo's suggestion is correct. If you want the method handle
> call to apply the maximum set of conversions, you should use
> `invokeWithArguments`.
>
> 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).
>
> 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).
>
> 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.
>
> Cheers
> Maurizio
>
> On 27/09/2023 10:29, Glavo wrote:
>> See MethodHandle::invokeWithArguments.
>>
>> Glavo
>>
>> On Wed, Sep 27, 2023 at 5:14 PM tison <wander4096 at gmail.com>
>> wrote:
>>
>> I'm using OpenJDK 21 and prototyping FFM APIs.
>>
>> Instead of passing the MethodHandle returned
>> by linker.downcallHandle here and there, I'm trying to
>> wrap it into a NativeMethod class:
>>
>> public final class NativeMethod {
>> private final String name;
>> private final FunctionDescriptor descriptor;
>> private final MethodHandle handle;
>> public Object invoke(Object... args) throws Throwable {
>> return this.handle.invoke(args);
>> }
>> }
>>
>> But it seems the varargs pass through is not quit fluent:
>>
>> java.lang.invoke.WrongMethodTypeException: cannot convert
>> MethodHandle(int)int to (Object[])Object
>>
>> at
>> java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:903)
>> at
>> java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:870)
>> at
>> java.base/java.lang.invoke.Invokers.checkGenericType(Invokers.java:541)
>> at
>> io.montumi.datafusion.core.NativeMethod.invoke(NativeMethod.java:22)
>>
>> While if I public the handle and call invoke from the
>> handle directly, all the behavior is expected.
>>
>> Best,
>> tison.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230927/02a502ee/attachment-0001.htm>
More information about the panama-dev
mailing list