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

\end{document}

