JNI light: an operational model for the core JNI

Abstract

Abstract. Through foreign function interfaces (FFIs), software components in different programming languages interact with each other in the same address space. Recent years have witnessed a number of systems that analyze FFIs for safety and reliability. However, lack of formal specifications of FFIs hampers progress in this endeavor. We present a formal operational model, JNI Light (JNIL), for a subset of a widely used FFI-the Java Native Interface (JNI). JNIL focuses on the core issues when a high-level garbage-collected language interacts with a low-level language. It proposes abstractions for handling a shared heap, crosslanguage method calls, cross-language exception handling, and garbage collection. JNIL can directly serve as a formal basis for JNI tools and systems. The abstractions in JNIL are also useful when modeling other FFIs, such as the Python/C interface and the OCaml/C interface. MotivationMost modern programming languages support foreign function interfaces (FFIs) for interoperating with program modules developed in other programming languages. Recent years have witnessed a string of systems that analyze and improve FFIs for safety and reliability [1,2,3,4,5,6,7,8]. However, lack of formal semantics of FFIs hampers progress in this domain. The available specifications of FFIs are in prose. Relying on prose specifications has at least two unpleasant consequences. First, prose specifications are often ambiguous and sometimes incomplete. The situation is especially acute for an FFI, whose two sides involve different programming models and language features. For instance, Lee et al. reported that Sun's HotSpot and IBM's J9 behave differently for four out of ten JNI test cases [8, Table 1]. In such situations, the best an FFI user can do is to perform experiments on particular implementations and make an educated guess. This may cause inconsistencies and unsoundness. Second, without formal semantics, tools and analyzers cannot provide rigorous claims about their strength. As a result, previous systems that target FFIs have to argue their hypotheses and claims informally. This leaves their strength in doubt.While there have been many efforts in formalizing the semantics of programming languages, almost all have ignored the FFI aspect. The work by Matthews and Findler [9] formalizes the interoperation between two high-level functional languages, one typed and the other untyped. While this formalism represents significant progress in modeling language interoperation, it does not apply to FFIs. Most FFIs are about the interaction in the shared memory between a high-level language and a low-level language (assembly languages, C, and C++).This paper presents the first formal operational model, named JNI Light (JNIL), for a subset of a shared-memory foreign function interface-the JNI interface. The major challenge for the modeling effort is to have the right abstractions to accommodate differences between the programming models of Java and native code, without unduly complicating the model. This is challe...

FunTAL: reasonably mixing a functional language with assembly

“…However, their model lowlevel language is Scheme with reflection. Tan [23] describes a core model for JNI that mixes Java bytecode and assembly. As an application, they design a sound type system for their multi-language.…”

Exception analysis in the Java Native Interface

“…For the claim of soundness, we would need to (1) take a formalized semantics of C and the JNI, (2) formalize TurboJet, and (3) show that it can catch all relevant bugs. Although there has been efforts on formalizing C [24,25] and the JNI [26], they target only subsets of C and the JNI and omit many important language features. Therefore, a formal proof of soundness remains a difficult task.…”