[repolfx]

There's an effort to bring a more modern FFI to Java that works similar to the one described in the article, called project Panama. It has tools to convert C header files into the equivalent annotated Java definitions and is intended to help improve performance as well.

You can follow along here:

http://mail.openjdk.java.net/pipermail/panama-dev/

The same project is also adding support for writing vector code in Java (SSE, AVX etc).

[agibsonccc]

Disclaimer: I'm affiliated with a semi competing project to panama called javacpp: https://github.com/bytedeco/javacpp

I can say for a fact that panama is not seriously targeting this space. We implement a ton of that native code today that works with c++ and actual android today. We also handle gpus. Project panama is only targeting c, and even then will only do it a cross platform non committal fashion. They aren't doing it the way they should be in order to properly target native vectorized code.

We know this from experience, because this is all we do: https://github.com/deeplearning4j/deeplearning4j https://github.com/bytedeco/javacpp-presets

We tried seeing if we could get some of this work in to the JDK, but their goals fundamentally compete with what it takes to get vector math to be fast. It's also not nearly as ambitious as it needs to be to handle real world tensor workloads.

[bitmapbrother]

>Project panama is only targeting c, and even then will only do it a cross platform non committal fashion

John Rose of Oracle:

Panama is not just about C headers. It is about building a framework in which any data+function schema of APIs can be efficiently plugged into the JVM. So it's not just C or C++ but protocol specs and persistent memory structures and on-disk formats and stuff not invented yet. We've been relentless about designing the framework down to essential functionality (memory access and procedure calls), not just our (second-)favorite language or compiler.

The important deliverable of Panama is therefore not Posix bindings, but rather a language-neutral memory layout-and-access mechanism, plus a language-neutral (initially ABI-compliant) subroutine invocation mechanism. The jextract tool grovels over ANSI C (soon C++) schemas and translates to the layouts and function calls, bound helpfully to Java APIs with unsurprising names. But the jextract tool is just the first plugin of many.

We do look forward to building more plugins for more metadata formats outside the Java ecosystem, such as what you are building.

In fact, I expect that, in the long run, we will not build all of the plugins, but that people who invent new data schemas (or even data+function schemas or languages) will consider using our tools (layouts, binder, metadata annotations) to integrate with Java, instead of the standard technique, which is to write a set of Java native functions from scratch, or (if you are very clever) with tooling. The binder pattern, in particular, seems to be a great way to spin repetitive code for accessing data structures of all sorts, not just C or Java. I hope it will be used, eventually, in preference to static protocol compilers. The JVM is very good at on-line optimization, even of freshly spun code, so it is a natural framework for building a binder.

>They aren't doing it the way they should be in order to properly target native vectorized code.

Which is interesting since Intel is the one contributing the majority of the vector code changes.

[agibsonccc]

Yes that's what I stated above. I've also stated that I haven't just read the news. We've talked to that team physically. Being language/platform neutral does not mean it is going to fulfill most use cases people would have for c bindings. Java tends to be "good enough" for a lot of use cases out of the box. It might help a bit with libraries like netty and memory management, but it's not going to work on real world math code which, as I stated, is our main use case.

That codegen isn't going to match what you need to do for real speed on cpus or gpus when writing vectorized math code.

Re: his last point. That's exactly what we talked to that team about. We don't feel those tools are going to work for real world use cases. We already do the codegen and auto bindings/mapping ourselves in addition to the memory management ourselves.

[needusername]

I don't know, it looks as if you have to hardcode pointer sizes in the source code.

https://twitter.com/sundararajan_a/status/101507363642677248...

[chrisseaton]

Where are you seeing that? The pointer in that example doesn't have a hardcoded size.

[needusername]

u64 in the annotation value

Check out this document http://cr.openjdk.java.net/~mcimadamore/panama/panama-binder... for the syntax.