Foreign Function Interface - Operation of An FFI

Operation of An FFI

The primary function of a FFI is to mate the semantics and calling conventions of one programming language (the host language, or the language which defines the FFI), with the semantics and conventions of another (the guest language). This process must also take into consideration the runtime environments and/or application binary interfaces of both. This can be done in several ways:

• Requiring that guest-language functions which are to be host-language callable be specified or implemented in a particular way; often using a compatibility library of some sort.
• Use of a tool to automatically "wrap" guest-language functions with appropriate glue code, which performs any necessary translation.
• Use of wrapper libraries
• Restricting the set of host language capabilities which can be used cross-language. For example, C++ functions called from C may not (in general) include reference parameters or throw exceptions.

FFIs may be complicated by the following considerations:

• If one language supports garbage collection (GC) and the other does not; care must be taken that the non-GC language code doesn't do something to cause the GC to fail. In JNI, for example, C code which "holds on to" object references passed from Java must "register" this fact with the Java runtime; otherwise the referred-to objects may be garbage-collected if no more valid references to the object(s) exist within the Java environment. (The C code must likewise release such references manually when the corresponding object is no longer needed).
• Complicated or non-trivial objects or datatype may be difficult to map from one environment to another.
• It may not be possible for both languages to maintain references to the same instance of a mutable object, due to the mapping issue above.
• One or both languages may be running on a virtual machine (including different VMs).
• Cross language inheritance or other forms of type or object composition may be especially difficult.