X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=doc%2Fmips2java.tex;fp=doc%2Fmips2java.tex;h=0000000000000000000000000000000000000000;hb=35b4af7ef98c04944208a52dd230dd1c8803eed7;hp=2c271dfccba21a3d4bcc29aae04869e72fd0f129;hpb=c06ee2c4e324de51e88aac60f0c52d93fddb6be0;p=nestedvm.git diff --git a/doc/mips2java.tex b/doc/mips2java.tex deleted file mode 100644 index 2c271df..0000000 --- a/doc/mips2java.tex +++ /dev/null @@ -1,274 +0,0 @@ -% -% 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} -