Implementing JNI in Java for Jalap eno ~
Ton A. Ngo and Steve E. Smith
IBM T. J. Watson Research Center
Yorktown Heights, NY 10598
[email protected], [email protected], http://www.research.ibm.com/jalap eno
Develop ed at the IBM T. J. Watson Re- This approach leads to two imp ortant soft-
search Center, Jalape~no [1] is a Java vir- ware engineering b ene ts. First, anyinternal
tual machine (JVM) written in Java that tar- change in Jalap eno ~ is transparent to the JNI
gets high-p erformance servers. The strate- implementation. Second, being written in
gic decision early in the pro ject to imple- Java, the implementation for these JNI func-
ment Jalap eno ~ in Java [2] leads to many im- tions is completely p ortable when Jalap eno ~ is
portant advantages, but also several implica- p orted to a new platform, even though it is
tions; therefore when the Java Native Inter- by de nition a nativeinterface.
face (JNI) was implemented for Jalap eno, ~ we
were heavily in uenced by this philosophy. In
this short pap er, we present a JNI implemen-
2 Stub compiler
1
tation that is written in Java . We discuss the
advantages and implications that arise from
For a Java metho d to call a native func-
aJava implementation.
tion and vice versa, we must be able to
transfer control between the two environ-
ments. Since Jalap eno ~ uses its own conven-
1 JNI Functions in Java
tion for stack frames and registers, this trans-
fer consists of mapping between Jalape~no
The bulk of the JNI sp eci cation [3] consists
convention and the nativeconvention. Since
over 200 functions accessible through a JNI
Jalap eno ~ is a compile-only JVM, a runtime
environmentpointer that allow nativecodeto
stub compiler generates the prologue and epi-
access Java ob jects or invokeJava metho ds in
logue surrounding the native pro cedure or
the JVM. In large part, these have a similar
Java metho d that is being called. The sp e-
functionality to the standard Java re ection
cial prologue establishes a transition frame on
interface. Since Jalap eno ~ already implements
the stack to conform to the callee's conven-
Java re ection based on Jalap eno's ~ own low-
tion byshuing the parameters in the stack
level internal re ection interface, there is a
frame and in the registers. Similarly, the epi-
strong motivation to reuse the same internal
logue ensures that the return value matches
re ection interface instead of adding a sep-
the exp ected convention in the caller.
arate interface to access the JVM internal
structures.
The transfer from Java to C involves all
native pro cedures that implement Java na-
In Jalape~no it is natural that we implement
tive metho ds. These pro cedures are nor-
the set of JNI functions in Java, rather than
mally packaged in a library that is loaded
in C as maybeexpected. This allows most of
from a Java program. As a class is loaded in
the functions to implement the required func-
Jalap eno, ~ its native metho ds are linked to a
tionalityby simply invoking the appropriate
sp ecial static metho d in the compiler. When
internal Jalape~no re ection metho ds. Many
a native metho d is invoked for the rst time,
cases only require a few lines of Javacode.
this sp ecial metho d attempts to resolve the
native metho d with the corresp onding pro ce-
1
Except for a small set of JNI functions intended
dure in the library. It then invokes the stub
to b e invoked outside the JVM, e.g. to create a JVM.
compiler to generate the prologue and epi- These functions by necessity are written in C.
logue and links it with the native pro cedure ator then consults the side stack to rep ort the
found in the library. Finally, the new co de lo cation of references asso ciated with these
is backpatched to b ecome the actual co de native stack frames. This approach allows
for the native metho d. A b ene t with this native co des to conform to a uniform garbage
lazy compilation approach is that only native collection interface that accommo dates all of
metho ds that are called require compilation. Jalap eno ~ garbage collectors.
The transfer from C to Java involves the
4 Conclusions
JNI functions describ ed ab ove. For conve-
nience, these functions are collected in one
Written in Javaandinterfacing directly with
class that implements a sp ecial nativeInter-
the internal JVM re ection, the Jalape~no
face. When this class is loaded and its meth-
JNI implementation is simple, p ortable, and
ods are dynamically compiled into machine
transparent to changes in the JVM internal
co de, the runtime compiler recognizes the
structures. The scheme for capturing all ob-
sp ecial nativeInterface and invokes the stub
jects passed to the native co des allows any
compiler to generate the necessary prologue
garbage collection p olicy to b e explored with
and epilogue.
no limitation.
Currently, our JNI implementation on the
3 References and GC
PowerPC/AIX platform is completed and we
are p orting to the Intel/Linux platform. This
For research purp oses, Jalap eno ~ hosts a fam-
will only require rewriting the stub compiler
ily of dynamic compilers and typ e accurate
for the Linux stack and register convention.
garbage collectors; therefore it is imp ortant
The few JNI functions written in C should
that no limitation on the GC p olicy arises
only require some minimal p orting e ort. We
from a JNI implementation. The JNI sp ec-
are also investigating issues concerning the in-
i cation provides for this capability by only
teraction b etween Java and native programs.
allowing the native co de to op erate on Java
ob jects through the well-de ned interface.
References
In Jalap eno ~ JNI, no direct p ointer to a Java
ob ject is passed to the native co de since this
[1] B. Alp ern, C. R. Attanasio, J. J. Barton,
would prevent the GC from scanning for the
M. G. Burke, P. Cheng, J.-D. Choi, A.
pointer and up dating it. Instead, eachJava
Co cchi, S. J. Fink, D. Grove, M. Hind,
ob ject to b e passed to the nativecodeissaved
S. F. Hummel, D. Lieb er, V. Litvinov,
in a side stack and an ID is given to the na-
M. F. Mergen, T. Ngo, J. R. Russell,
tive co de in its place. When the nativecode
V. Sarkar, M. J. Serrano, J. C. Shep-
returns an ob ject ID to the caller or passes
herd, S. E. Smith, V. C. Sreedhar, H.
an ob ject ID to a JNI function (in Java), the
Srinivasan, and J. Whaley. The Jalape~no
actual ob ject is retrieved from the side stack.
Virtual Machine, IBM Systems Journal,
The prologue and epilogue p erform the push-
2000, Vol39,No1,pp211-238.
ing and p opping of ob jects to/from the side
stack as needed.
[2] B. Alp ern, D. Attanasio, J. Barton, A.
Co cchi, S. Hummel, D. Lieb er, T. Ngo,
During a garbage collection cycle, the stack
M. Mergen, J. Shepherd, and S. E.
is scanned for references. All Jalap eno ~ com-
Smith, Implementing Jalape~no in Java,
pilers implement a StackMapIterator class
ACM SIGPLAN Conference on Ob ject-
which presents a common interface for rep ort-
Oriented Programming Systems, Lan-
ing the lo cation of live references in the stack
guages and Applications (OOPSLA),
frames of the metho ds they have compiled.
Novemb er 1999, pp 314-324.
The Jalap eno ~ JNI implementation follows
this mechanism byproviding a StackMapIter- [3] S. Liang, The Java Native Interface,
ator whichisinvoked for each contiguous se- Programmer's Guide and Speci cation,
quence of native frames in the stack. The iter- Addison-Wesley Publishers (1999).