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.
  21
  22         The Mono runtime can be used as a stand-alone process, or it
  23         can be <a href="embedded-api">embedded into applications</a> (see
  24         the documentation in mono/samples/embed for more details).
  25
  26         Embedding the Mono runtime allows applications to be extended
  27         in C# while reusing all of the existing C and C++ code.
  28
  29         Paolo Molaro did a presentation on the current JIT engine and
  30         the new JIT engine.  You can find his <a
  31         href="http://primates.ximian.com/~lupus/slides/jit/">slides
  32         here</a>
  33
  34 ** Current JIT Engine (<b>updated, July 8th, 2002</b>)
  35
  36         The JIT engine uses a code-generator generator approach for
  37         compilation.  Given the properties of CIL byte codes, we can
  38         take full advantage of a real instruction selector for our
  39         code generator.
  40
  41         The JIT engine implements a number of optimizations:
  42
  43         <ul>
  44                 * Opcode cost estimates (our architecture allows
  45                   us to generate different code paths depending
  46                   on the target CPU dynamically).
  47
  48                 * Inlining.
  49
  50                 * Constant folding.
  51
  52                   Although compilers typically do
  53                   constant folding, the combination of inlining with
  54                   constant folding gives some very good results.
  55
  56                 * Linear scan register allocation.  In the past,
  57                   register allocation was our achilles heel, but now
  58                   we have left this problem behind.
  59         </ul>
  60
  61         There are a couple of books that deal with this technique: "A
  62         Retargetable C Compiler" and "Advanced Compiler Design and
  63         Implementation" are good references.  You can also get a
  64         technical description of <a
  65         href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
  66
  67         A few papers that describe the instruction selector:
  68
  69         <ul>
  70                 * <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>
  71
  72
  73                 * <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>
  74
  75         </ul>
  76
  77 ** New JIT engine.
  78
  79         We are working on a new JIT engine.  The new JIT engine
  80         focuses on portability and in two intermediate representations
  81         that simplify the development of optimizations.  This together
  82         with the Ahead-of-Time compilation will allow developers to
  83         deploy applications that match the speed of natively compiled code.
  84
  85 ** Garbage Collection
  86
  87         Currently we are using the Boehm conservative GC.  Although our plans
  88         are to move to the Intel ORP GC engine, our plans on a next generation
  89         dual-JIT engine have to be taken into account.
  90
  91         We will be using the Intel ORP GC engine as it provides a precise
  92         garbage collector engine, similar to what is available on the
  93         .NET environment.
  94
  95         Although using a conservative garbage collector like Bohem's
  96         would work, all the type information is available at runtime,
  97         so we can actually implement a better collector than a
  98         conservative collector.
  99
 100         <ul>
 101                 * Garbage collection list and FAQ:<br>
 102                   <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
 103
 104                 * "GC points in a Threaded Environment":<br>
 105                   <a href="http://research.sun.com/techrep/1998/abstract-70.html">
 106                   http://research.sun.com/techrep/1998/abstract-70.html</a>
 107
 108                 * "A Generational Mostly-concurrent Garbage Collector":
 109                   <a href="http://research.sun.com/techrep/2000/abstract-88.html">
 110                   http://research.sun.com/techrep/2000/abstract-88.html</a>
 111
 112                 * Details on The Microsoft .NET Garbage Collection Implementation:<br>
 113                   <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>
 114                   <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>
 115         </ul>
 116
 117 ** IO and threading
 118
 119         The ECMA runtime and the .NET runtime assume an IO model and a
 120         threading model that is very similar to the Win32 API.
 121
 122         Dick Porter has been working on the Mono abstraction layer
 123         that allows our runtime to execute code that depend on this
 124         behaviour.
 125
 126 ** Useful links
 127
 128         Paolo Molaro found a few interesting links:
 129
 130         <ul>
 131                 * On compilation of stack-based languages:<br>
 132                 <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
 133                 http://www.complang.tuwien.ac.at/projects/rafts.html</a>
 134
 135                 * A paper on fast JIT compilation of a stack-based language:<br>
 136                   <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
 137                   http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
 138
 139                 * Vmgen generates much of the code for efficient virtual machine (VM)
 140                   interpreters from simple descriptions of the VM instructions:<br>
 141                   <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
 142                   http://www.complang.tuwien.ac.at/anton/vmgen</a>
 143         </ul>
 144
 145 ** PInvoke
 146
 147         PInvoke is the mechanism we are using to wrap Unix API calls
 148         as well as talking to system libraries.
 149
 150         Initially we used libffi, but it was fairly slow, so we have
 151         reused parts of the JIT work to create efficient PInvoke trampolines.
 152
 153 ** Remoting
 154
 155         Mono has support for remoting and proxy objects, just like
 156         .NET does.  The runtime provides these facilities.
 157
 158 ** Porting
 159
 160         If you are interested in porting the Mono runtime to other
 161         platforms, you might find the pre-compiled <a
 162         href="archive/mono-tests.tar.gz">Mono regression test
 163         suite</a> useful to debug your implementation.
 164
 165 * COM and XPCOM
 166
 167         We plan on adding support for XPCOM on Unix and COM on Microsoft
 168         Windows later in our development process.
 169