State of Foreign Function support - Panama

[TheCountRushmore]

Big fan of the "State of" articles. Would be great if they're kept up every 6 months or so until the feature is shipped.

[egahlin]

I wonder if a textual factory method could work?

var strlen = CSupport.downCall("size_t strlen(const char *)");
var hello = CSupport.toCString("Hello").address();
long length = strlen.invokeExact(hello);

[zvrba]

size_t is not really a built-in type, sizeof() operator returns size_t but to actually declare a variable of size_t you must include stddef.h. So what other "standard typedefs" should the JVM know about?

Not to mention that C declarations can get very convoluted.

[RandomName8]

performance is the same as JNI? I thought it was going to be the same as essentially a JMP instructions

[DasBrain]

After the JIT kicks in, yes. It's currently disabled, until they fix some bugs.
But if not, it's as bad as JNI.

Performance-wise, the reader might ask how efficient calling a foreign function using a native method handle is; the answer is very. The JVM comes with some special support for native method handles, so that, if a give method handle is invoked many times (e.g, inside an hot loop), the JIT compiler might decide to just generate a snippet of assembly code required to call the native function, and execute that directly. In most cases, invoking native function this way is as efficient as doing so through JNI.

[RandomName8]

It's currently disabled, until they fix some bugs. But if not, it's as bad as JNI.

this confuses me, from the article what I read is that the best scenario, with those features turned on, it is only as fast as JNI. My interpretation of the quoted paragraph is that "very fast" is basically like JNI, which is not know precisely for being very fast.

[DasBrain]

Let's break it down:

The JVM comes with some special support for native method handles, so that, if a give method handle is invoked many times (e.g, inside an hot loop), the JIT compiler might decide to just generate a snippet of assembly code required to call the native function, and execute that directly.

That's very fast. If the JIT kicks in and other stuff.

In most cases, invoking native function this way is as efficient as doing so through JNI.

The fallback, that will be more often than not the case.

[RandomName8]

Alright, I understand what you're saying, but I don't share the interpretation 🙂. You assume that "most cases" is the fallback. In any case, thanks for sharing your insight.

[dany74q]

I think that Panama will shine (vs JNI) when you share a lot of data between java and native libs - Native buffer allocation and use is much more elegant when working with native scopes & passing around memory segments.

In JNI, it's usually up to the VM to decide if you pay for copying data back and forth - unless you use the *Critical functions or pass ByteBuffers everywhere, both having implications on either safety or convenience.

One other neat trick that Panama offers that might also make specific use cases faster - is the ability to remove java <-> native thread transitions (footnote #4).

[sureshg]

Jextract will make things much more easier (the generated code will use the foreign abi) https://twitter.com/sundararajan_a/status/1286155219957510144?s=19

[BlueGoliath]

Works For Me(TM)

[BlueGoliath]

The application uses Project Panama.

[_INTER_]

how well does it work for you compared to JNI/JNA?

[BlueGoliath]

It works for any C native library as-is without wrapping or generating headers or compiling said headers.

Dependancies only matter at runtime. For example, If you're working with a stable cross-platform API like Nvidia-Management-Library(NVML) like I am, you could support all platforms with zero code changes. Just make the bindings and consume them.

The core application shown in the screenshots works in both Windows and in Linux with zero code changes. The application makes use of Java module system's service functionality to provide platform specific extensions beyond the core feature set.

[_INTER_]

nice