doc/mips2java.tex

   1 %
   2 % FIXME: - Add something about size limits on the constant pool
   3 %          how we worked around that and the performance impact
   4 %          of -o lessconstants
   5 %        - Add something about encoding data sections as string constants
   6 %          and the UTF8 non-7-bit-ascii penalty
   7 %
   8
   9 \documentclass{acmconf}
  10 \usepackage{graphicx}
  11 \usepackage{amssymb,amsmath,epsfig,alltt}
  12 \sloppy         % better line breaks
  13 \usepackage{palatino}
  14 \usepackage{parskip}
  15 \usepackage{tabularx}
  16 \usepackage{alltt}
  17 \bibliographystyle{alpha}
  18
  19 \title{\textbf{\textsf{
  20 Running Legacy C/C++ Libraries in a Pure Java Environment
  21 }}}
  22 \date{}
  23 \author{\begin{tabular}{@{}c@{}}
  24         {\em {Brian Alliet}} \\ \\
  25         {{\it Affiliation Goes Here}}\relax
  26    \end{tabular}\hskip 1in\begin{tabular}{@{}c@{}}
  27         {\em {Adam Megacz}} \\ \\
  28         {UC Berkeley}\relax
  29 \end{tabular}}
  30 \begin{document}
  31
  32 \maketitle
  33
  34 \begin{abstract}
  35 Abstract
  36 \end{abstract}
  37
  38 \section{Introduction}
  39
  40 \subsection{Why would you want to do this?}
  41
  42 The C programming language has been around for over 30 years now.
  43 There is a huge library of software written in this language.  By
  44 contrast, Java has been around for less than ten years.  Although it
  45 offers substantial advantages over C, the set of libraries written in
  46 this language still lags behind C/C++.
  47
  48 The typical solution to this dilemma is to use JNI or CNI to invoke C
  49 code from within a Java VM.  Unfortunately, there are a number of
  50 situations in which this is not an acceptable solution:
  51
  52 \begin{itemize}
  53 \item Java Applets are not permitted to invoke {\tt Runtime.loadLibrary()}
  54 \item Java Servlet containers with a {\tt SecurityManager} will not
  55       permit loading new JNI libraries.  This configuration is popular
  56       with {\it shared hosting} providers and corporate intranets
  57       where a number of different parties contribute individual web
  58       applications which are run together in a single container.
  59 \item JNI requires the native library to be compiled ahead of time,
  60       separately, for every architecture on which it will be deployed.
  61       This is unworkable for situations in which the full set of
  62       target architectures is not known at deployment time.
  63 \item The increasingly popular J2ME platform does not support JNI or CNI.
  64 \item Unlike Java Bytecode, JNI code is susceptible to buffer overflow
  65       and heap corruption attacks.  This can be a major security
  66       vulnerability.
  67 \item JNI often introduces undesirable added complexity to an
  68       application.
  69 \end{itemize}
  70
  71 The technique we present here is based on using a typical ANSI C
  72 compiler to compile C/C++ code into a MIPS binary, and then using a
  73 tool to translate that binary on an instruction-by-instruction basis
  74 into Java bytecode.
  75
  76 The technique presented here is general; we anticipate that it can be
  77 applied to other secure virtual machines such as Microsoft's .NET.
  78
  79
  80 \section{Existing Work: Source-to-Source Translation}
  81
  82 \begin{itemize}
  83 \item c2java
  84 \item commercial products
  85 \end{itemize}
  86
  87 \section{Mips2Java: Binary-to-Binary Translation}
  88
  89 We present Mips2Java, a binary-to-binary translation tool to convert
  90 MIPS binaries into Java bytecode files.
  91
  92 The process of utilizing Mips2Java begins by using any compiler for
  93 any language to compile the source library into a statically linked
  94 MIPS binary.  We used {\tt gcc 3.3.3}, but any compiler which can
  95 target the MIPS platform should be acceptable.  The binary is
  96 statically linked with a system library (in the case of C code this is
  97 {\tt libc}) which translates system requests (such as {\tt open()},
  98 {\tt read()}, or {\tt write()}) into appropriate invocations of the
  99 MIPS {\tt SYSCALL} instruction.
 100
 101 The statically linked MIPS binary is then fed to the Mips2Java tool
 102 (which is itself written in Java), which emits a sequence of Java
 103 Bytecodes in the form of a {\tt .class} file equivalent to the
 104 provided binary.  This {\tt .class} file contains a single class which
 105 implements the {\tt Runtime} interface.  This class may then be
 106 instantiated; invoking the {\tt execute()} method is equivalent to
 107 invoking the {\tt main()} function in the original binary.
 108
 109
 110 \subsection{Why MIPS?}
 111
 112 We chose MIPS as a source format for two primary reasons: the
 113 availability of tools to translate legacy code into MIPS binaries, and
 114 the close similarity between the MIPS ISA and the Java Virtual Machine.
 115
 116 The MIPS architecture has been around for quite some time, and is well
 117 supported by the GNU Compiler Collection, which is capable of
 118 compiling C, C++, Java, Fortran, Pascal (with p2c), and Objective C
 119 into MIPS binaries.
 120
 121 The MIPS R1000 ISA bears a striking similarity to the Java Virtual
 122 Machine.  This early revision of the MIPS supports only 32-bit aligned
 123 loads and stores from memory, which is precisely the access model
 124 supported by Java for {\tt int[]}s.
 125
 126 Cover dynamic page allocation.
 127
 128 Cover stack setup.
 129
 130 Brian, are there any other fortunate similarities we should mention
 131 here?  I seem to remember there being a bunch, but I can't recall them
 132 right now; it's been a while since I dealt with this stuff in detail.
 133
 134
 135 \subsection{Interpreter}
 136
 137 \begin{itemize}
 138 \item slow, but easy to write
 139 \end{itemize}
 140
 141
 142 \subsection{Compiling to Java Source}
 143 \begin{itemize}
 144 \item performance boost
 145 \item pushes the limits of {\tt javac} and {\tt jikes}
 146 \end{itemize}
 147
 148 \subsection{Compiling directly to Java Bytecode}
 149 \begin{itemize}
 150 \item further performance boost (quantify)
 151 \item brian, can you add any comments here?
 152 \end{itemize}
 153
 154 \subsection{Interfacing with Java Code}
 155
 156 Java source code can create a copy of the translated binary by
 157 instantiating the corresponding class, which extends {\tt Runtime}.
 158 Invoking the {\tt main()} method on this class is equivalent to
 159 calling the {\tt main()} function within the binary; the {\tt String}
 160 arguments to this function are copied into the binary's memory space
 161 and made available as {\tt argv**} and {\tt argc}.
 162
 163 The translated binary communicates with the rest of the VM by
 164 executing MIPS {\tt SYSCALL} instructions, which are translated into
 165 invocations of the {\tt syscall()} method.  This calls back to the
 166 native Java world, which can manipulate the binary's environment by
 167 reading and writing to its memory space, checking its exit status,
 168 pausing the VM, and restarting the VM.
 169
 170
 171 \subsection{Virtualization}
 172
 173 The {\tt Runtime} class implements the majority of the standard {\tt
 174 libc} syscalls, providing a complete interface to the filesystem,
 175 network socket library, time of day, (Brian: what else goes here?).
 176
 177 \begin{itemize}
 178 \item ability to provide the same interface to CNI code and mips2javaified code
 179 \item security advantages (chroot the {\tt fork()}ed process)
 180 \end{itemize}
 181
 182 \section{Related Work}
 183
 184 \subsection{Source-to-Source translators}
 185
 186 A number of commercial products and research projects attempt to
 187 translate C++ code to Java code, preserving the mapping of C++ classes
 188 to Java classes.  Unfortunately this is problematic since there is no
 189 way to do pointer arithmetic except within arrays, and even in that
 190 case, arithmetic cannot be done in terms of fractional objects.
 191
 192 Mention gcc backend
 193
 194 c2java
 195
 196 Many of these products advise the user to tweak the code which results
 197 from the translation.  Unfortunately, hand-modifying machine-generated
 198 code is generally a bad idea, since this modification cannot be
 199 automated.  This means that every time the origin code changes, the
 200 code generator must be re-run, and the hand modifications must be
 201 performed yet again.  This is an error-prone process.
 202
 203 Furthermore, Mips2Java does not attempt to read C code directly.  This
 204 frees it from the complex task of faithfully implementing the ANSI C
 205 standard (or, in the case of non ANSI-C compliant code, some other
 206 interface).  This also saves the user the chore of altering their
 207 build process to accomodate Mips2Java.
 208
 209
 210 \section{Performance}
 211
 212 \subsection{Charts}
 213
 214 (Note that none of these libraries have pure-Java equivalents.)
 215
 216 \begin{itemize}
 217 \item libjpeg
 218 \item libfreetype
 219 \item libmspack
 220 \end{itemize}
 221
 222
 223 \subsection{Optimizations}
 224
 225 Brian, can you write something to go here?  Just mention which
 226 optimizations helped and which ones hurt.
 227
 228 \begin{itemize}
 229 \item trampoline
 230 \item optimal method size
 231 \item -msingle-float
 232 \item -mmemcpy
 233 \item fastmem
 234 \item local vars for registers (useless)
 235 \item -fno-rename-registers
 236 \item -ffast-math
 237 \item -fno-trapping-math
 238 \item -fsingle-precision-constant
 239 \item -mfused-madd
 240 \item -freg-struct-return
 241 \item -freduce-all-givs
 242 \item -fno-peephole
 243 \item -fno-peephole2
 244 \item -fmove-all-movables
 245 \item -fno-sched-spec-load
 246 \item -fno-sched-spec
 247 \item -fno-schedule-insns
 248 \item -fno-schedule-insns2
 249 \item -fno-delayed-branch
 250 \item -fno-function-cse
 251 \item -ffunction-sections
 252 \item -fdata-sections
 253 \item array bounds checking
 254 \item -falign-functions=n
 255 \item -falign-labels=n
 256 \item -falign-loops=n
 257 \item -falign-jumps=n
 258 \item -fno-function-cse
 259 \end{itemize}
 260
 261 \section{Future Directions}
 262
 263 World domination.
 264
 265 \section{Conclusion}
 266
 267 We rock the hizzouse.
 268
 269 \section{References}
 270
 271 Yer mom.
 272
 273 \end{document}
 274