Pre-draft FFI JEP

[Charles Oliver Nutter]

I have written up a pre-draft JDK Enhancement Proposal for FFI, and
figured that folks on this list would be good reviewers.

https://gist.github.com/headius/8670271

I hope to submit this tomorrow (Jan 29) and ideally get a JEP number
assigned before my talk on JNR this Saturday at FOSDEM. Please try to
get comments to me in the next 24 hours.

I also hope to talk to some of you at FOSDEM or JFokus about JNR and
the future of FFI on the Java platform!

- Charlie

[Charles Oliver Nutter]

Comments and replies from Ioannis Tsakpinis, of the LWJGL project:

> Just read the JEP, I think it's great and I don't have anything to add at
> this point. The only thing I found a bit odd was mention of (new?) native
> memory management. Which NIO's direct buffers basically is. Correct me if
> I'm wrong, but my guess is that you're talking about something lower-level
> (an official Unsafe?), something that could have been used together with the
> FFI to implement everything in NIO. And not the other way around, like my
> suggestion above to use direct buffers as a pointer abstraction in the FFI.
> Btw (you've probably seen this already) Oracle is already open to
> discussions about Unsafe:
> https://blogs.oracle.com/dave/entry/do_you_use_sun_misc

Will have a look at that blog post.

WRT native memory, I agree that this isn't much more than direct
ByteBuffer in implementation. What JNA and JNR provide is a Java-level
abstraction atop that so you don't have to manually marshal values
to/from memory. So the JEP (and eventual JSR) would essentially make
it possible for user code to define a "super-ByteBuffer" that is
backed by native memory but knows about struct layout and value
marshaling (and perhaps lifecycle).

> Oh, a thought I just had. Should the JEP include something about callback
> functions? Right now that's a bit of a pain for us, callbacks from C to Java
> code is the only functionality we have to code manually in LWJGL. I know
> there's dynamic native code generation magic that can be used to handle this
> (JNA & JNR do it too iirc), but I wonder if there's a better way with a
> built-in FFI in the JVM. Threading issues exist here too, callbacks can
> either be synchronous (from a JVM thread) or asynchronous (from a native
> thread). Anyway, this isn't too important for us (not many callbacks to
> support), but it'd be nice to get rid of JNI completely.

I don't know if that's the level of detail we need to have in the JEP,
but it's a good thought. I also don't call out how call protocols
should work, how specific types should marshal. Callbacks may be a big
enough item to mention explicitly.

[George Marrows]

There's lots of discussions on JNI / Unsafe / ByteBuffers etc over on Mechanical Sympathy. You might want to cross-post there. JNR has already had a mention or two.

https://groups.google.com/forum/#!forum/mechanical-sympathy

-- George

[Charles Oliver Nutter]

Thanks for that! I've cross-posted and invited folks there to join the
discussion.

- Charlie

> --
> You received this message because you are subscribed to the Google Groups
> "jvm-ffi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jvm-ffi+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Tomasz Kowalczewski]

Read the JEP, nice work!

For me the most interesting part is "Mechanisms for binding, based on metadata, a specific memory structure (layout, endianness, logical types) to a Java endpoint". It would be nice to have something like Packed Objects from IBM, or ObjectLayout from Gil Tene and Martin Thompson. Is this the direction you intend to go? That would be a lot of work for a JEP.

Btw. one typo I noticed:
"Beyond simply writing C code, developers must be able to build that code for each platform they __which__ to support"

--

Regards,

Tomasz Kowalczewski

[Martijn Verburg]

I've pinged to the Friends of jClarity list as well - already a few extra readers - proposal looks pretty good to me.  I know the IBM folks had elements of this idea with their PackedObjects proposal (in terms of replacing JNI in some use cases), might be worth chatting to Steve Poole over there (he won't be @ FOSDEM).

See you in a couple of days!

Cheers,
Martijn

Visit this group at http://groups.google.com/group/jvm-ffi.
To view this discussion on the web visit https://groups.google.com/d/msgid/jvm-ffi/CANTKXYkhxQnex2_m-QYriy3Z%2B_JNgxjnh%3DQ0bud4gxVp8bbMwA%40mail.gmail.com.

[Noctarius]

@Tomasz, @headius,

To support structs / PacketObject like stuff it might be interesting to inter coorperate with our JEP proposal for sun.misc.Unsafe as a public API and general offheap support (https://groups.google.com/forum/#!forum/jep-off-heap).

Chris

Visit this group at http://groups.google.com/group/jvm-ffi.
To view this discussion on the web visit https://groups.google.com/d/msgid/jvm-ffi/CANTKXYkhxQnex2_m-QYriy3Z%2B_JNgxjnh%3DQ0bud4gxVp8bbMwA%40mail.gmail.com.

[Charles Oliver Nutter]

On Tue, Jan 28, 2014 at 8:44 PM, Tomasz Kowalczewski
<tomasz.ko...@gmail.com> wrote:
> Read the JEP, nice work!

Thanks!

> For me the most interesting part is "Mechanisms for binding, based on
> metadata, a specific memory structure (layout, endianness, logical types) to
> a Java endpoint". It would be nice to have something like Packed Objects
> from IBM, or ObjectLayout from Gil Tene and Martin Thompson. Is this the
> direction you intend to go? That would be a lot of work for a JEP.

This could dovetail with a packed object JEP or JSR, but it is out of
scope for this JEP (see Non-Goals section). This JEP will only
encompass the management and access of memory blocks used to call
native code.

> Btw. one typo I noticed:
> "Beyond simply writing C code, developers must be able to build that code
> for each platform they __which__ to support"

Fixed, thanks!

- Charlie

[Charles Oliver Nutter]

On Tue, Jan 28, 2014 at 8:46 PM, Noctarius <noctar...@googlemail.com> wrote:
> @Tomasz, @headius,
>
> To support structs / PacketObject like stuff it might be interesting to
> inter coorperate with our JEP proposal for sun.misc.Unsafe as a public API
> and general offheap support
> (https://groups.google.com/forum/#!forum/jep-off-heap).

Excellent, thank you! I'm glad to hear there's interest in the "other
side" of native memory management. There's definitely some synergy
between these proposals.

Anything we do for one should keep in mind the other, so I've applied
to join your off-heap JEP group and I hope you will actively
participate here as well.

- Charlie

[Noctarius]

Sure count me in. JFFI looked very promissing (and it was faster
than JNA for some older of my tests).

Chris

> - Charlie
>

[Remi Forax]

On 01/28/2014 08:48 PM, Charles Oliver Nutter wrote:
> On Tue, Jan 28, 2014 at 8:44 PM, Tomasz Kowalczewski
> <tomasz.ko...@gmail.com> wrote:
>> Read the JEP, nice work!
> Thanks!
>
>> For me the most interesting part is "Mechanisms for binding, based on
>> metadata, a specific memory structure (layout, endianness, logical types) to
>> a Java endpoint". It would be nice to have something like Packed Objects
>> from IBM, or ObjectLayout from Gil Tene and Martin Thompson. Is this the
>> direction you intend to go? That would be a lot of work for a JEP.
> This could dovetail with a packed object JEP or JSR, but it is out of
> scope for this JEP (see Non-Goals section). This JEP will only
> encompass the management and access of memory blocks used to call
> native code.

The access to memory blocks is the tricky point of this JEP.
There is clearly a mismatch between a C struct (or array of structs)
allocated on stack and a Java object (or an array of ...) allocated on heap.
The conservative way to solve that issue is to have one Java object for
one C struct and copy the data back and forth. Now, given that we may
have value types in 9, my fear is that it will postpone this JEP.
I think this should be noted somewhere in this JEP.

The two other points, how to call a C function from Java and how to have
the JIT to fold everything are easier because we have invokedynamic for
the former and we can introduce a new kind of method handle for the later.

>
>> Btw. one typo I noticed:
>> "Beyond simply writing C code, developers must be able to build that code
>> for each platform they __which__ to support"
> Fixed, thanks!
>
> - Charlie
>

cheers,
Rémi

[Charles Oliver Nutter]

On Tue, Jan 28, 2014 at 9:19 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
> The access to memory blocks is the tricky point of this JEP.
> There is clearly a mismatch between a C struct (or array of structs)
> allocated on stack and a Java object (or an array of ...) allocated on heap.
> The conservative way to solve that issue is to have one Java object for one
> C struct and copy the data back and forth. Now, given that we may have value
> types in 9, my fear is that it will postpone this JEP.
> I think this should be noted somewhere in this JEP.

I will add a mention under Risks and Assumptions. As I see it, the
absolute worst we could do would be copying back and forth, and the
more likely option is something ByteBuffer-like that has a Java object
wrapping a block of native memory and marshaling all types across.
Given that ByteBuffer exists already, I don't see this as a big
blocker for the FFI JEP, but there's definitely an opportunity to
*improve* the JEP if value types or off-heap data get into 9 as well.

> The two other points, how to call a C function from Java and how to have the
> JIT to fold everything are easier because we have invokedynamic for the
> former and we can introduce a new kind of method handle for the later.

Yes, that aligns with what John Rose described at JVMLS. Note that
jnr-ffi already does have a degree of invokedynamic support. This is
currently only used by JRuby (in our Ruby FFI impl) but it effectively
causes the JIT to bind the lowest-level jffi downcall directly to the
call site with a bit of argument-wrangling around it (i.e. the Ruby
code making a programmatically-defined FFI call eventually JITs as a
trivial static call the appropriate jffi "native" endpoint). That
combined with jnr's runtime generation of JNI stubs is damn near the
fastest we can get FFI atop JNI. I'm hoping that the JEP can go
further once we're able to present call metadata directly to the JVM.

- Charlie

[Charles Oliver Nutter]

I have submitted the JEP and will update the group when it is accepted
into the archive.

- Charlie

[Christoph Engelbert]

*thumbs up*