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 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 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).