Anthony Cocchi

Implementing jalapeño in Java

Jalapeño is a virtual machine for Java#8482; servers written in Java. A running Java program involves four layers of functionality: the user code, the virtual-machine, the operating system, and the hardware. By drawing the Java / non-Java boundary below the virtual machine rather than above it, Jalapeño reduces the boundary-crossing overhead and opens up more opportunities for optimization. To get Jalapeño started, a boot image of a working Jalapeño virtual machine is concocted and written to a file. Later, this file can be loaded into memory and executed. Because the boot image consists entirely of Java objects, it can be concocted by a Java program that runs in any JVM. This program uses reflection to convert the boot image into Jalapeños object format. A special MAGIC class allows unsafe casts and direct access to the hardware. Methods of this class are recognized by Jalapeños three compilers, which ignore their bytecodes and emit special-purpose machine code. User code will not be allowed to call MAGIC methods so Javas integrity is preserved. A small non-Java program is used to start up a boot image and as an interface to the operating system. Javas programming features — object orientation, type safety, automatic memory management — greatly facilitated development of Jalapeño. However, we also discovered some of the languages limitations.

Efficient implementation of Java interfaces: Invokeinterface considered harmless

Single superclass inheritance enables simple and efficient table-driven virtual method dispathc. However, virtual method table dispatch does not handle multiple inheritance and interfaces. This complication has led to a widespread misimpression that interface method dispatch is inherently inefficient. This paper argues that with proper implementation techniques, Java interfaces need not be a source of significant performance degradation.

A comparative evaluation of parallel garbage collector implementations

While uniprocessor garbage collection is relatively well understood, experience with collectors for large multiprocessor servers is limited and it is unknown which techniques best scale with large memories and large numbers of processors. In order to explore these issues we designed a modular garbage collection framework in the IBM Jalapeno Java virtual machine and implemented five different parallel garbage collectors: non-generational and generational versions of mark-and-sweep and semi-space copying collectors, as well as a hybrid of the two. We describe the optimizations necessary to achieve good performance across all of the collectors, including load balancing, fast synchronization, and inter-processor sharing of free lists. We then quantitatively compare the different collectors to find their asymptotic performance both with respect to how fast they can run applications as well as how little memory they can run them in. All of our collectors scale linearly up to sixteen processors. The least memory is usually required by the hybrid mark-sweep collector that uses a copying collector for its nursery, although sometimes the non-generational mark-sweep collector requires less memory. The fastest execution is more application-dependent. Our only application with a large working set performed best using the mark-sweep collector; with one exception, the rest of the applications ran fastest with one of the generational collectors.

Dynamic linking on a shared-memory multiprocessor

This paper presents a technique for back-patching instructions in an SMP environment. This technique is used by the Jalapeno virtual machine to support dynamic class loading in Java. There is a small runtime overhead the first time a back-patch site is executed. Thereafter, it executes at the same speed as equivalent sites not requiring back-patching.

Efficient Dispatch of Java Interface Methods

Virtual methods can be dispatched efficiently because the code for corresponding methods reside at the same entries in their respective virtual method tables (VMTs). To achieve efficient interface method dispatch, a fixed-sized interface method table (IMT) is associated with each class. Different implementations of the same interface method signature reside at the same entry in their respective IMTs. When a class implements two or more interface methods with the same IMT offset, a conflict resolution stub distinguishes between them at runtime. The resulting interface method dispatch is almost as cheap as its virtual counterpart.