• Abstract and Figures
• Public Full-text

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

Load more

  2

Copy Link