integrated Brians comments on ivme paper

[nestedvm.git] / doc / nestedvm.ivme04.tex

%
% FIXME: - Add something about size limits on the constant pool
%          how we worked around that and the performance impact
%          of -o lessconstants
%        - Add something about encoding data sections as string constants
%          and the UTF8 non-7-bit-ascii penalty 
%

\documentclass{acmconf}
\usepackage{graphicx}
\usepackage{amssymb,amsmath,epsfig,alltt}
\sloppy         % better line breaks
\usepackage{palatino}
\usepackage{parskip}
\usepackage{tabularx}
\usepackage{alltt}
\bibliographystyle{alpha}

\title{\textbf{\textsf{
Running Legacy C/C++ Libraries in a Pure Java Environment
}}}
\date{}
\author{\begin{tabular}{@{}c@{}}
        {\em {Brian Alliet}} \\ \\
        {{\it Affiliation Goes Here}}\relax
   \end{tabular}\hskip 1in\begin{tabular}{@{}c@{}}
        {\em {Adam Megacz}} \\ \\
        {UC Berkeley}\relax
\end{tabular}}
\begin{document}

\maketitle

\begin{abstract}
Abstract
\end{abstract}

\section{Introduction}

\subsection{Why would you want to do this?}

The C programming language has been around for over 30 years now.
There is a huge library of software written in this language.  By
contrast, Java has been around for less than ten years.  Although it
offers substantial advantages over C, the set of libraries written in
this language still lags behind C/C++.

The typical solution to this dilemma is to use JNI or CNI to invoke C
code from within a Java VM.  Unfortunately, there are a number of
situations in which this is not an acceptable solution:

\begin{itemize}
\item Java Applets are not permitted to invoke {\tt Runtime.loadLibrary()}
\item Java Servlet containers with a {\tt SecurityManager} will not
      permit loading new JNI libraries.  This configuration is popular
      with {\it shared hosting} providers and corporate intranets
      where a number of different parties contribute individual web
      applications which are run together in a single container.
\item JNI requires the native library to be compiled ahead of time,
      separately, for every architecture on which it will be deployed.
      This is unworkable for situations in which the full set of
      target architectures is not known at deployment time.
\item The increasingly popular J2ME platform does not support JNI or CNI.
\item Unlike Java Bytecode, JNI code is susceptible to buffer overflow
      and heap corruption attacks.  This can be a major security
      vulnerability.
\item JNI often introduces undesirable added complexity to an
      application.
\end{itemize}

The technique we present here is based on using a typical ANSI C
compiler to compile C/C++ code into a MIPS binary, and then using a
tool to translate that binary on an instruction-by-instruction basis
into Java bytecode.

The technique presented here is general; we anticipate that it can be
applied to other secure virtual machines such as Microsoft's .NET.


\section{Existing Work: Source-to-Source Translation}

\begin{itemize}
\item c2java
\item commercial products
\end{itemize}

\section{Mips2Java: Binary-to-Binary Translation}

We present Mips2Java, a binary-to-binary translation tool to convert
MIPS binaries into Java bytecode files.

The process of utilizing Mips2Java begins by using any compiler for
any language to compile the source library into a statically linked
MIPS binary.  We used {\tt gcc 3.3.3}, but any compiler which can
target the MIPS platform should be acceptable.  The binary is
statically linked with a system library (in the case of C code this is
{\tt libc}) which translates system requests (such as {\tt open()},
{\tt read()}, or {\tt write()}) into appropriate invocations of the
MIPS {\tt SYSCALL} instruction.

The statically linked MIPS binary is then fed to the Mips2Java tool
(which is itself written in Java), which emits a sequence of Java
Bytecodes in the form of a {\tt .class} file equivalent to the
provided binary.  This {\tt .class} file contains a single class which
implements the {\tt Runtime} interface.  This class may then be
instantiated; invoking the {\tt execute()} method is equivalent to
invoking the {\tt main()} function in the original binary.


\subsection{Why MIPS?}

We chose MIPS as a source format for two primary reasons: the
availability of tools to translate legacy code into MIPS binaries, and
the close similarity between the MIPS ISA and the Java Virtual Machine.

The MIPS architecture has been around for quite some time, and is well
supported by the GNU Compiler Collection, which is capable of
compiling C, C++, Java, Fortran, Pascal (with p2c), and Objective C
into MIPS binaries.

The MIPS R1000 ISA bears a striking similarity to the Java Virtual
Machine.  This early revision of the MIPS supports only 32-bit aligned
loads and stores from memory, which is precisely the access model
supported by Java for {\tt int[]}s.

Cover dynamic page allocation.

Cover stack setup.

Brian, are there any other fortunate similarities we should mention
here?  I seem to remember there being a bunch, but I can't recall them
right now; it's been a while since I dealt with this stuff in detail.


\subsection{Interpreter}

\begin{itemize}
\item slow, but easy to write
\end{itemize}


\subsection{Compiling to Java Source}
\begin{itemize}
\item performance boost
\item pushes the limits of {\tt javac} and {\tt jikes}
\end{itemize}

\subsection{Compiling directly to Java Bytecode}
\begin{itemize}
\item further performance boost (quantify)
\item brian, can you add any comments here?
\end{itemize}

\subsection{Interfacing with Java Code}

Java source code can create a copy of the translated binary by
instantiating the corresponding class, which extends {\tt Runtime}.
Invoking the {\tt main()} method on this class is equivalent to
calling the {\tt main()} function within the binary; the {\tt String}
arguments to this function are copied into the binary's memory space
and made available as {\tt argv**} and {\tt argc}.

The translated binary communicates with the rest of the VM by
executing MIPS {\tt SYSCALL} instructions, which are translated into
invocations of the {\tt syscall()} method.  This calls back to the
native Java world, which can manipulate the binary's environment by
reading and writing to its memory space, checking its exit status,
pausing the VM, and restarting the VM.


\subsection{Virtualization}

The {\tt Runtime} class implements the majority of the standard {\tt
libc} syscalls, providing a complete interface to the filesystem,
network socket library, time of day, (Brian: what else goes here?).

\begin{itemize}
\item ability to provide the same interface to CNI code and mips2javaified code
\item security advantages (chroot the {\tt fork()}ed process)
\end{itemize}

\section{Related Work}

\subsection{Source-to-Source translators}

A number of commercial products and research projects attempt to
translate C++ code to Java code, preserving the mapping of C++ classes
to Java classes.  Unfortunately this is problematic since there is no
way to do pointer arithmetic except within arrays, and even in that
case, arithmetic cannot be done in terms of fractional objects.

Mention gcc backend

c2java

Many of these products advise the user to tweak the code which results
from the translation.  Unfortunately, hand-modifying machine-generated
code is generally a bad idea, since this modification cannot be
automated.  This means that every time the origin code changes, the
code generator must be re-run, and the hand modifications must be
performed yet again.  This is an error-prone process.

Furthermore, Mips2Java does not attempt to read C code directly.  This
frees it from the complex task of faithfully implementing the ANSI C
standard (or, in the case of non ANSI-C compliant code, some other
interface).  This also saves the user the chore of altering their
build process to accomodate Mips2Java.


\section{Performance}

\subsection{Charts}

(Note that none of these libraries have pure-Java equivalents.)

\begin{itemize}
\item libjpeg
\item libfreetype
\item libmspack
\end{itemize}


\subsection{Optimizations}

Brian, can you write something to go here?  Just mention which
optimizations helped and which ones hurt.

\begin{itemize}
\item trampoline
\item optimal method size
\item -msingle-float
\item -mmemcpy
\item fastmem
\item local vars for registers (useless)
\item -fno-rename-registers
\item -ffast-math
\item -fno-trapping-math
\item -fsingle-precision-constant
\item -mfused-madd
\item -freg-struct-return
\item -freduce-all-givs
\item -fno-peephole
\item -fno-peephole2
\item -fmove-all-movables
\item -fno-sched-spec-load
\item -fno-sched-spec
\item -fno-schedule-insns
\item -fno-schedule-insns2
\item -fno-delayed-branch
\item -fno-function-cse
\item -ffunction-sections
\item -fdata-sections
\item array bounds checking
\item -falign-functions=n
\item -falign-labels=n
\item -falign-loops=n
\item -falign-jumps=n
\item -fno-function-cse
\end{itemize}

\section{Future Directions}

World domination.

\section{Conclusion}

We rock the hizzouse.

\section{References}

Yer mom.

\section{stuff}
\begin{verbatim}

libjpeg (render thebride_1280.jpg)
Native -  0.235s
JavaSource - 1.86s
ClassFile - 1.37s

freetype (rendering characters 32-127 of Comic.TTF at sizes from 8 to
48 incrementing by 4)
Native - 0.201s
JavaSource - 2.02s
ClassFile - 1.46s

Section 3.2  - Interpreter
The Interpreter was the first part of Mips2Java to be written.  This was the most 
straightforward and simple way to run MIPS binaries inside the JVM.  The simplicity of the 
interpreter also made it very simple to debug. Debugging machine-generated code is a pain. 
Most importantly, the interpreter provided a great reference to use when developing the 
compiler. With known working implementations of each MIPS instruction in Java writing a 
compiler became a matter of simple doing the same thing ahead of time.
With the completion of the compiler the interpreter in Mips2Java has become less useful. 
However, it may still have some life left in it. One possible use is remote debugging with 
GDB. Although debugging the compiler generated JVM code is theoretically possible, it 
would be far easier to do in the interpreter. The interpreter may also be useful in cases 
where size is far more important than speed. The interpreter is very small. The interpreter 
and MIPS binary combined are smaller than the compiled classfiles.
Section 3.3 - Compiling to Java Source
The next major step in Mips2JavaÕs development was the Java source compiler. This 
generated Java source code (compliable with javac or Jikes) from a MIPS binary. 
Generating Java source code was preferred initially over JVM bytecode for two reasons. 
The authors werenÕt very familiar with JVM bytecode and therefore generating Java source 
code was simpler. Generating source code also eliminated the need to do trivial 
optimizations in the Mips2java compiler that javac and Jikes already do. This mainly 
includes 2+2=4 stuff. For example, the MIPS register r0 is immutable and always 0. This 
register is represented by a static final int in the Java source compiler. Javac and Jikes 
automatically handle optimizing this away when possible. In the JVM bytecode compiler 
these optimizations needs to be done in Mips2Java.
Early versions of the Mips2Java compiler were very simple. All 32 MIPS GPRs and a 
special PC register were fields in the generated java class. There was a run() method 
containing all the instructions in the .text segment converted to Java source code. A switch 
statement was used to allow jumps from instruction to instruction. The generated code 
looked something like this.
private final static int r0 = 0;
private int r1, r2, r3,...,r30;
private int r31 = 0xdeadbeef;
private int pc = ENTRY_POINT;

public void run() {
        for(;;) {
        switch(pc) {
                case 0x10000:
                        r29 = r29 Ð 32;
                case 0x10004:
                        r1 = r4 + r5;
                case 0x10008:
                        if(r1 == r6) {
                                /* delay slot */
                                r1 = r1 + 1;
                                pc = 0x10018:
                                continue;
                        }
                case 0x1000C:
                        r1 = r1 + 1;
                case 0x10010:
                        r31 = 0x10018;
                        pc = 0x10210;
                        continue;
                case 0x10014:
                        /* nop */
                case 0x10018:
                        pc = r31;
                        continue;
                ...
                case 0xdeadbeef:
                        System.err.println("Exited from ENTRY_POINT");
                        System.err.println("R2: " + r2);
                        System.exit(1);
        }
        }
}

This worked fine for small binaries but as soon as anything substantial was fed to it the 64k 
JVM method size limit was soon hit. The solution to this was to break up the code into 
many smaller methods. This required a trampoline to dispatch  jumps to the appropriate 
method. With the addition of the trampoline the generated code looked something like this:
public void run_0x10000() {
        for(;;) {
        switch(pc) {
                case 0x10000:
                        ...
                case 0x10004:
                        ...
                ...
                case 0x10010:
                        r31 = 0x10018;
                        pc = 0x10210;
                        return;
                ...
        }
        }
}

pubic void run_0x10200() {
        for(;;) {
        switch(pc) {
                case 0x10200:
                        ...
                case 0x10204:
                        ...
        }
        }
}

public void trampoline() {
        for(;;) {
        switch(pc&0xfffffe00) {
                        case 0x10000: run_0x10000(); break;
                        case 0x10200: run_0x10200(); break;
                        case 0xdeadbe00:
                                ...
                }
        }
}
With this trampoline in place somewhat large binaries could be handled without much 
difficulty. There is no limit on the size of a classfile as a whole, just individual methods. 
This method should scale well. However, there are other classfile limitations that will limit 
the size of compiled binaries.
Another interesting problem that was discovered while creating the trampoline method was 
javac and JikesÕ incredible stupidity when dealing with switch statements. The follow code 
fragment gets compiled into a lookupswich by javac:
Switch(pc&0xffffff00) {
        Case 0x00000100: run_100(); break;
        Case 0x00000200: run_200(); break;
        Case 0x00000300: run_300(); break;
}
while this nearly identical code fragment gets compiled to a tableswitch
switch(pc>>>8) {
        case 0x1: run_100(); break
        case 0x2: run_200(); break;
        case 0x3: run_300(); break;
}
Javac isnÕt smart enough to see the patter in the case values and generates very suboptimal 
bytecode. Manually doing the shifts convinces javac to emit a tableswitch statement, which 
is significantly faster. This change alone nearly doubled the speed of the compiled binary.
Finding the optimal method size lead to the next big performance increase.  It was 
determined with experimentation that the optimal number of MIPS instructions per method 
is 128 (considering only power of two options). Going above or below that lead to 
performance decreases. This is most likely due to a combination of two factors.
_ The two levels  of switch statements jumps have to pass though Ð The first switch 
statement jumps go through is the trampoline switch statement. This is implemented 
as a TABLESWITCH in JVM bytecode so it is very fast. The second level switch 
statement in the individual run_ methods is implemented as a LOOKUPSWITCH, 
which is much slower. Using smaller methods puts more burden on the faster 
TABLESWITCH and less on the slower LOOKUPSWITCH.
_ JIT compilers probably favor smaller methods smaller methods are easier to compile 
and are probably better candidates for JIT compilation than larger methods.
FIXME: Put a chart here
The next big optimization was eliminating unnecessary case statements. Having case 
statements before each instruction prevents JIT compilers from being able to optimize 
across instruction boundaries. In order to eliminate unnecessary case statements every 
possible address that could be jumped to directly needed to be identified. The sources for 
possible jump targets come from 3 places.
_ The .text segment Ð Every instruction in the text segment in scanned for jump 
targets. Every branch instruction (BEQ, JAL, etc) has its destination added to the list 
of possible branch targets. In addition, functions that set the link register have 
theirpc+8 added to the list (the address that wouldÕve been put to the link register). 
Finally, combinations of LUI (Load Upper Immediate) of ADDIU (Add Immediate 
Unsigned) are scanned for possible addresses in the text segment. This combination 
of instructions is often used to load a 32-bit word into a register.
_ The .data segment Ð When GCC generates switch() statements it often uses a jump 
table stored in the .data segment. Unfortunately gcc doesnÕt identify these jump 
tables in any way. Therefore, the entire .data segment is conservatively scanned for 
possible addresses in the .text segment.
_ The symbol table Ð This is mainly used as a backup. Scanning the .text and .data 
segments should identify any possible jump targets but adding every function in the 
symbol table in the ELF binary doesnÕt hurt. This will also catch functions that are 
never called directly from the MIPS binary (for example, functions called with the 
call() method in the runtime).
Eliminating unnecessary case statements provided a 10-25% speed increase .
Despite all the above optimizations and workaround an impossible to workaround hard 
classfile limit was eventually hit, the constant pool. The constant pool in classfiles is limited 
to 65536 entries. Every Integer with a magnitude greater than 32767 requires an entry in the 
constant pool. Every time the compiler emits a jump/branch instruction the PC field is set to 
the branch target. This means nearly every branch instruction requires an entry in the 
constant pool. Large binaries hit this limit fairly quickly. One workaround that was 
employed in the Java source compiler was to express constants as offsets from a few central 
values. For example: "pc = N_0x00010000 + 0x10" where N_0x000100000 is a non-
final field to prevent javac from inlining it. This was sufficient to get reasonable large 
binaries to compile. It has a small (approximately 5%) performance impact on the generated 
code. It also makes the generated classfile somewhat larger. Fortunately, the classfile 
compiler eliminates this problem.
3.4 Ð Bytecode compiler
The next step in the evolution of Mips2Java was to compile directly to JVM bytecode 
eliminating the intermediate javac step. This had several advantages
_ There are little tricks that can be done in JVM bytecode that canÕt be done in Java 
source code.
_ Eliminates the time-consuming javac step Ð Javac takes a long time to parse and 
compile the output from the java source compiler.
_ Allows for MIPS binaries to be compiled and loaded into a running VM using a 
class loader. This eliminates the need to compile the binaries ahead of time. 
By generating code at the bytecode level  there are many areas where the compiler can be 
smarter than javac. Most of the areas where improvements where made where in the 
handling of branch instructions and in taking advantage of the JVM stack to eliminate 
unnecessary LOADs and STOREs to local variables.
The first obvious optimization that generating bytecode allows for is the use of GOTO. 
Despite the fact that java doesnÕt have a GOTO keyword  a GOTO bytecode does exist and 
is used heavily in the code generates by javac. Unfortunately the java language doesnÕt 
provide any way to take advantage of this. As result of this jumps within a method were 
implemented by setting the PC field to the new address and making a trip back to the initial 
switch statement.  In the classfile compiler these jumps are implemented as GOTOs directly 
to the target instruction. This saves a costly trip back through the LOOKUPSWITCH 
statement and is a huge win for small loops within a method.
Somewhat related to using GOTO is the ability to optimize branch statements. In the Java 
source compiler branch statements are implemented as follows (delay slots are ignored for 
the purpose of this example)
If(condition) { pc = TARGET; continue; }
This requires a branch in the JVM regardless of whether the MIPS branch is actually taken. 
If condition is false the JVM has to jump over the code to set the PC and go back to the 
switch block. If condition is true the JVM as to jump to the switch block. By generating 
bytecode directly we can make the target of the JVM branch statement the actual bytecode 
of the final destination. In the case where the branch isnÕt taken the JVM doesnÕt need to 
branch at all.
A side affect of the above two optimizations is a solution to the excess constant pool entries 
problem. When jumps are implemented as GOTOs and direct branches to the target the PC 
field doesnÕt need to be set. This eliminates many of the constant pool entries the java 
source compiler requires. The limit is still there however, and given a large enough binary it 
will still be reached.
Delay slots are another area where things are done somewhat inefficiently in the Java source 
compiler. In order to take advantage of instructions already in the pipeline MIPS cpu have a 
"delay slot". That is, an instruction after a branch or jump instruction that is executed 
regardless of whether the branch is taken. This is done because by the time the branch or 
jump instruction is finished being processes the next instruction is already ready to be 
executed and it is wasteful to discard it. (However, newer  MIPS CPUs have pipelines that 
are much larger than early MIPS CPUs so they have to discard many instructions anyway.) 
As a result of this the instruction in the delay slot is actually executed BEFORE the branch 
is taken. To make things even more difficult, values from the register file are loaded 
BEFORE the delay slot is executed.  Here is a small piece of MIPS assembly:
ADDIU r2,r0,-1
BLTZ r2, target
ADDIU r2,r2,10
...
:target
This piece of code is executed as follows
1. r2 is set to Ð1
2. r2 is loaded from the register file by the BLTEZ instruction
3. 10 is added to r2 by the ADDIU instruction
4. The branch is taken because at the time the BLTZ instruction was executed r2 was 
Ð1, but r2 is now 9 (-1 + 10)
There is a very element solution to this problem when using JVM bytecode. When a branch 
instruction is encountered the registers needed for the comparison are pushed onto the stack 
to prepare for the JVM branch instruction. Then, AFTER the values are on the stack the 
delay slot is emitted, and then finally the actual JVM branch instruction. Because the values 
were pushed to the stack before the delay slot was executed any changes the delay slot made 
to the registers are not visible to the branch bytecode. This allows delay slots to be used 
with no performance penalty or size penalty. 
One final advantage that generating bytecode directly allows is smaller more compact 
bytecode. All the optimization above lead to smaller bytecode as a side effect. There are also 
a few other areas where the generated bytecode can be optimized for size with more 
knowledge of the program as a whole.
When encountering the following switch block both javac and Jikes generate redundant 
bytecode.
Switch(pc>>>8) {
        Case 0x1: run_1(); break;
        Case 0x2: run_2(); break
        ...
        case 0x100: run_100(); break;
}
The first bytecode in each case arm in the switch statement is ALOAD_0 to prepare for a 
invoke special call. By simple moving this outside the switch statement  each case arm was 
reduced in size by one instruction. Similar optimizations were also done in other parts of the 
compiler.

Section 3 
- Adam - The method is run(), not execute. Execute() is only used when you need to 
resume from a pause syscall.

Section 3.1
- Adam - Even the R1000 supports LB/SB/LH/SH/LWL/LWR Ð saying it only supports 
32-bit aligned loads is incorrect.
- Other similarities
o All the branching instructions in MIPS directly map to single JVM instructions.
o Most of the ALU instructions map to single JVM instructions.

(I can write up some stuff for each of these next several sections if you want)
Section 3.2  - Interpreter
- Originally written mainly to understand the MIPS instruction set
- Far easier to debug than an ahead of time compiler (no waiting, can throw in quick 
hacks like if(pc >= 0xbadc0de && pc <= 0xbadcfff) debugOutput() ), donÕt need to 
understand most of the ELF format)
- Still could be useful
o for GDB remote debugging
o cases where size is more important than speed (size of interpreter + size of mips 
binary < size of compiled binary or size of compiler + mips binary)
o code which dynamically generates code (JIT compilers, etc). The ahead of time 
compiler canÕt possibly handle this

Section 3.3 Ð Compiling to Java Source
- First version of an ahead of time compiler
- Huge performance boost
- Java source output preferred for the 2+2=4 type optimizations java compilers do
- Worked well for small binaries Ð large MIPS binaries required ridiculous amounts of 
memory to compile and often created  invalid classfiles
- Too many constants Ð every jump operation required an entry in the constant pool (pc = 
0xabcd1234; continue; )

Section 3.4 Ð Compiling directly to JVM Bytecode
- Another jump in performance
- More efficient code can be created at the bytecode level
o Information can be stored on the JVM stack rather than in local variables
_ Javac/jikes often unnecessarily use local variables
long tmp = a*b;
lo = (int)tmp;
hi = (int)(tmp>>>32)
does a store and two loads when a simple DUP would suffice
o GOTO can be used to branch directly  to branch destinations in the same method 
rather than going through the switch block again.
o BEQ, BGTZ, BLE, etc can jump directly to destination rather than doing 
if(condition) { pc=0xabcd1234; continue; }
o Eliminates excess constant pool entries (only jump outside the current method 
require a constant pool entry)
o Delay slots implemented more efficiently.
_ Java source compiler does:
if(condition) { /* delay slot /; pc = 0xabcd1234; continue; }
/* delay slot again */
_ This is required because the delay slot can change the registers used in 
condition. The registers need to be read BEFORE the delay slot in executed.
_ In the bytecode compiler the registers used in the condition are pushed to the 
stack, then the delay slot is executed, and finally the comparison is done. 
This eliminates the needs to output the delay slot twice.
- Smaller bytecode
o Everything mentioned above makes it smaller and faster
o Javac/jikes add redundant code
_ Switch(a) {
   Case 1: Run_1000(); break;
   Case 2: run_2000(); break;
}
Gets compiled into
1 ÐTableswitch É. 
2 Ð ALOAD_0
3 Ð invokespecial  run_1000
4 Ð goto end
5 Ð ALOAD_0
6 Ð invokespecial run_2000
10 Ð goto end
ALOAD_0 is unnecessarily put in each switch arm

3.5 Interfacing with Java Code
- _call_java ()/Runtime.call()
o _call_java () - Call a java method from mips
o Runime.call() Ð call a mips method from java
o Easily allocate memory within the binaryÕs memory space by calling libcÕs malloc()
o Can go back and forth between mips and java (java calls mips which calls java which 
calls back into mips)
- Java Strings can easily be converted to and from null terminated strings in the processÕ 
memory space
- Java InputStreams, OutputStreams, and Sockets can easily be turned in to standard 
UNIX file descriptors (and ANSI FILE*s)
- Can easily create custom filedescriptors and have full control over all operations on 
them (read, write, seek, close, fstat, etc)
- Int User_info[] Ð optional chunk of memory can very easily be accessed from java 
(Runtime.getUserInfo/setUserInfo)

3.6 Virtualization
- Adam Ð we actually donÕt support sockets directly yet Ð you should probably take that 
out. (But you can create a socket in java and expose it to mips as a filedescriptor)
- Runtime services
o Provides a easy to use interface to subclasses (Interpreter or compiles binaries)
_ Subclasses only know how to execute instructions
_ Runtime handles setting up registers/stack for execution to begin and 
extracting return values and the exit status from the process
o Memory management 
_ Sets up stack and guard pages
_ Allocates pages with the sbrk syscall
_ Provide easy an memcpy like interface for accessing the processes memory 
from java
o Runtime.call() support Ð sets up registers,etc to prepare the process for a call into it 
from java
o Filesystem Ð open/close/read/write/seek/fcntl s syscalls
o Time related functions Ð sleep, gettimeofday, times syscall
o UnixRuntime provides a more complete unix-like environment (Runtime smaller 
though)
_ Supports fork() and waitpid()
_ Pipe() for IPC
_ More advocated filesystem interface
_ All filesystem operations abstracted away into a FileSystem class
o FileSystem class can be written that exposes a zip file, 
directory on an http server, etc as a filesystem
_ Chdir/getcwd
_ /dev filesystem
_ stat()
_ directory listing support
5.1 Charts
IÕll put together some charts tonight
5.2 Optimizations
And finish this part

Let me know if this was what you were looking for

                                          libjpeg  libmspack libfreetype
Interpreted MIPS Binary                   22.2      12.9      21.4
Compled MIPS Binary (fastest options)     3.39      2.23      4.31
Native -O3                                0.235    0.084     0.201

Compled - with all case statements        3.50      2.30      4.99
Compiled - with pruned case statement     3.39      2.23      4.31

Compiled - 512 instructions/method        62.7      27.7      56.9
Compiled - 256 instructions/method        3.54      2.55      4.43
Compiled - 128 instructions/method        3.39      2.23      4.31
Compiled - 64 instructions/method         3.56      2.31      4.40
Compiled - 32 instruction/method          3.71      2.46      4.64

Compild MIPS Binary (Server VM)           3.21      2.00      4.54
Compiled MIPS Binary (Client VM)          3.39      2.23      4.31

All times are measured in seconds. These were all run on a dual 1ghz G4
running OS X 10.3.1 with Apple's latest VM (JDK 1.4.1_01-27). Each test
was run 8 times within a single VM. The highest and lowest times were
removed and the remaining 6 were averaged. In each case only the first
run differed significantly from the rest.

The libjpeg test consisted of decoding a 1280x1024 jpeg
(thebride_1280.jpg) and writing a tga. The mspack test consisted of
extracting all members from arial32.exe, comic32.exe, times32.exe, and
verdan32.exe. The freetype test consisted of rendering characters
32-127 of Comic.TTF at sizes from 8 to 48 incrementing by 4. (That is
about 950 individual glyphs).

I can provide you with the source for any of these test if you'd like.

-Brian
\end{verbatim}

\end{document}