+++ /dev/null
-%
-% 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}
-
projects / nestedvm.git / blobdiff