web/runtime

   1 * The Mono runtime
   2
   3         The Mono runtime implements a JIT engine for the CIL virtual
   4         machine (as well as a byte code interpreter, this is to
   5         quickly port it to new systems), the class loader, the garbage
   6         collector, threading system and metadata access libraries.
   7
   8         We currently have two runtimes:
   9
  10         <ul>
  11                 * <b>mono:</b> The Just In Time compiler implemented
  12                   using a BURS instruction selector.  We only support
  13                   x86 machines in the JIT engine at this point.
  14
  15                 * <b>mint:</b> The Mono interpreter.  This is an
  16                   easy-to-port runtime engine.
  17         </ul>
  18
  19         Currently we are using the Bohem conservative garbage
  20         collector, but we working on incorporating the ORP GC engine.
  21
  22 ** Executing MSIL/CIL images
  23
  24         The code will load an executable and map the references to
  25         external assemblies to our own version of the assemblies on
  26         Linux.
  27
  28         Our roadmap looks like this, this has been updated as of
  29         <b>Dec 18, 2001</b>:
  30
  31         <ul>
  32
  33                 * Milestone 1: <b>Done</b> Fully read and parse all CIL byte-codes
  34                   and metadata tokens (ie, a disassembler).
  35
  36                 * Milestone 2: <b>Done</b> Complete an interpreter for CIL byte
  37                   codes.  This interpreter can be used temporarly to
  38                   run CIL byte code on a system where no JIT is
  39                   available.
  40
  41                 * Milestone 3: <b>Done</b>Define an <i>lburg</i>-like
  42                   instruction selector for the JITer for Intel.
  43
  44                 * Milestone 4: <b>Done</b> Implement JITer.  This is where our
  45                   current efforts are focused on, the JITer currently runs
  46                   all of the code we have tested on it.  The major limitation
  47                   is that our class libraries are not complete, and hence not
  48                   every application can be ran.
  49
  50                 * Milestone 5: Port of the JITer to non IA32 systems.
  51         </ul>
  52
  53         A setup similar to the Kaffe JIT engine will be used to
  54         layout the code to support non-IA32 architectures.  Our work
  55         will be focused on getting a IA32 version running first.
  56
  57         The JIT engine works on Linux and Win32, although you
  58         will need to install the CygWin32 development tools to get a
  59         Unix-like compilation environment (mostly we use GNU make in
  60         a few of the makefiles).
  61
  62 ** JIT Engine (<b>updated, July 8th, 2002</b>)
  63
  64         The JIT engine uses a code-generator generator approach for
  65         compilation.  Given the properties of CIL byte codes, we can
  66         take full advantage of a real instruction selector for our
  67         code generator.
  68
  69         The JIT engine implements a number of optimizations:
  70
  71         <ul>
  72                 * Opcode cost estimates (our architecture allows
  73                   us to generate different code paths depending
  74                   on the target CPU dynamically).
  75
  76                 * Inlining.
  77
  78                 * Constant folding.
  79
  80                   Although compilers typically do
  81                   constant folding, the combination of inlining with
  82                   constant folding gives some very good results.
  83
  84                 * Linear scan register allocation.  In the past,
  85                   register allocation was our achilles heel, but now
  86                   we have left this problem behind.
  87         </ul>
  88
  89         There are a couple of books that deal with this technique: "A
  90         Retargetable C Compiler" and "Advanced Compiler Design and
  91         Implementation" are good references.  You can also get a
  92         technical description of <a
  93         href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
  94
  95         A few papers that describe the instruction selector:
  96
  97         <ul>
  98                 * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/interface.pdf&pub=wiley">A code generation interface for ANSI C</a>
  99
 100
 101                 * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">Engineering efficient code generators using tree matching and dynamic programming.</a>
 102
 103         </ul>
 104
 105 ** Future plans
 106
 107         We are evaluating the future directions for the JIT engine:
 108         both from our needs (optimizations like inlining, better register allocation,
 109         instruction scheduling, and porting to other CPUs).
 110
 111         We have not yet decided how we will evolve the JIT engine.  We
 112         might just upgrade our current architecture, and provide optimizations as
 113         an extra layer.
 114
 115 ** Garbage Collection
 116
 117         Currently we are using the Boehm conservative GC.  Although our plans
 118         are to move to the Intel ORP GC engine, our plans on a next generation
 119         dual-JIT engine have to be taken into account.
 120
 121         We will be using the Intel ORP GC engine as it provides a precise
 122         garbage collector engine, similar to what is available on the
 123         .NET environment.
 124
 125         Although using a conservative garbage collector like Bohem's
 126         would work, all the type information is available at runtime,
 127         so we can actually implement a better collector than a
 128         conservative collector.
 129
 130         <ul>
 131                 * Garbage collection list and FAQ:<br>
 132                   <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
 133
 134                 * "GC points in a Threaded Environment":<br>
 135                   <a href="http://research.sun.com/techrep/1998/abstract-70.html">
 136                   http://research.sun.com/techrep/1998/abstract-70.html</a>
 137
 138                 * "A Generational Mostly-concurrent Garbage Collector":
 139                   <a href="http://research.sun.com/techrep/2000/abstract-88.html">
 140                   http://research.sun.com/techrep/2000/abstract-88.html</a>
 141
 142                 * Details on The Microsoft .NET Garbage Collection Implementation:<br>
 143                   <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp</a>
 144                   <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp</a>
 145         </ul>
 146
 147 ** IO and threading
 148
 149         The ECMA runtime and the .NET runtime assume an IO model and a
 150         threading model that is very similar to the Win32 API.
 151
 152         Dick Porter has been working on the Mono abstraction layer
 153         that allows our runtime to execute code that depend on this
 154         behaviour.
 155
 156 ** Useful links
 157
 158         Paolo Molaro found a few interesting links:
 159
 160         <ul>
 161                 * On compilation of stack-based languages:<br>
 162                 <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
 163                 http://www.complang.tuwien.ac.at/projects/rafts.html</a>
 164
 165                 * A paper on fast JIT compilation of a stack-based language:<br>
 166                   <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
 167                   http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
 168
 169                 * Vmgen generates much of the code for efficient virtual machine (VM)
 170                   interpreters from simple descriptions of the VM instructions:<br>
 171                   <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
 172                   http://www.complang.tuwien.ac.at/anton/vmgen</a>
 173         </ul>
 174
 175 ** PInvoke
 176
 177         PInvoke is the mechanism we are using to wrap Unix API calls
 178         as well as talking to system libraries.
 179
 180         Initially we used libffi, but it was fairly slow, so we have
 181         reused parts of the JIT work to create efficient PInvoke trampolines.
 182
 183 ** Remoting
 184
 185         Mono has support for remoting and proxy objects, just like
 186         .NET does.  The runtime provides these facilities.
 187
 188 ** Porting
 189
 190         If you are interested in porting the Mono runtime to other
 191         platforms, you might find the pre-compiled <a
 192         href="archive/mono-tests.tar.gz">Mono regression test
 193         suite</a> useful to debug your implementation.
 194
 195 * COM and XPCOM
 196
 197         We plan on adding support for XPCOM on Unix and COM on Microsoft
 198         Windows later in our development process.
 199