web/runtime

   1 * The Mono runtime
   2
   3         The Mono runtime engine is considered feature complete.
   4
   5         It implements a Just-in-Time compiler engine for the CIL
   6         virtual machine, the class loader, the garbage collector,
   7         threading system and metadata access libraries.
   8
   9         We currently have two runtimes:
  10
  11         <ul>
  12                 * <b>mono:</b> Our Just-in-Time and Ahead-of-Time code
  13                   generator for maximum performance.
  14
  15                 * <b>mint:</b> The Mono interpreter.  This is an
  16                   easy-to-port runtime engine.
  17         </ul>
  18
  19         We are using the Boehm conservative garbage collector.
  20
  21         The Mono runtime can be used as a stand-alone process, or it
  22         can be <a href="embedded-api">embedded into applications</a> (see
  23         the documentation in mono/samples/embed for more details).
  24
  25         Embedding the Mono runtime allows applications to be extended
  26         in C# while reusing all of the existing C and C++ code.
  27
  28         Paolo Molaro did a presentation on the current JIT engine and
  29         the new JIT engine.  You can find his <a
  30         href="http://primates.ximian.com/~lupus/slides/jit/">slides
  31         here</a>
  32
  33 ** Current JIT Engine: technical details (<b>updated, June 28th, 2003</b>)
  34
  35         We have re-written our JIT compiler. We wanted to support a
  36         number of features that were missing:
  37
  38         <ul>
  39                 * Ahead-of-time compilation.
  40
  41              The idea is to allow developers to pre-compile their code
  42              to native code to reduce startup time, and the working
  43              set that is used at runtime in the just-in-time compiler.
  44
  45              Although in Mono this has not been a visible problem, we
  46              wanted to pro-actively address this problem.
  47
  48              When an assembly (a Mono/.NET executable) is installed in
  49              the system, it would then be possible to pre-compile the
  50              code, and have the JIT compiler tune the generated code
  51              to the particular CPU on which the software is
  52              installed.
  53
  54              This is done in the Microsoft.NET world with a tool
  55              called ngen.exe
  56
  57                 * Have a good platform for doing code optimizations.
  58
  59              The design called for a good architecture that would
  60              enable various levels of optimizations: some
  61              optimizations are better performed on high-level
  62              intermediate representations, some on medium-level and
  63              some at low-level representations.
  64
  65              Also it should be possible to conditionally turn these on
  66              or off.  Some optimizations are too expensive to be used
  67              in just-in-time compilation scenarios, but these
  68              expensive optimizations can be turned on for
  69              ahead-of-time compilations or when using profile-guided
  70              optimizations on a subset of the executed methods.
  71
  72                 * Reduce the effort required to port the Mono code
  73              generator to new architectures.
  74
  75              For Mono to gain wide adoption in the Unix world, it is
  76              necessary that the JIT engine works in most of today's
  77              commercial hardware platforms.
  78         </ul>
  79
  80         The JIT engine implements a number of optimizations:
  81
  82         <ul>
  83                 * Opcode cost estimates (our architecture allows
  84                   us to generate different code paths depending
  85                   on the target CPU dynamically).
  86
  87                 * Inlining.
  88
  89                 * Constant folding, copy propagation, dead code elimination.
  90
  91                   Although compilers typically do
  92                   constant folding, the combination of inlining with
  93                   constant folding gives some very good results.
  94
  95                 * Linear scan register allocation.  In the past,
  96                   register allocation was our achilles heel, but now
  97                   we have left this problem behind.
  98
  99                 * SSA-based framework.  Various optimizations are
 100                   implemented on top of this framework
 101         </ul>
 102
 103         There are a couple of books that deal with this technique: "A
 104         Retargetable C Compiler" and "Advanced Compiler Design and
 105         Implementation" are good references.  You can also get a
 106         technical description of <a
 107         href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
 108
 109         The new JIT engines uses three intermediate representations:
 110         the source is the CIL which is transformed into a forest of
 111         trees; This is fed into a BURS instruction selector that
 112         generates the final low-level intermediate representation.
 113
 114         The instruction selector is documented in the following
 115         papers:
 116
 117         <ul>
 118                 * <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>
 119
 120
 121                 * <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>
 122
 123         </ul>
 124
 125 ** Garbage Collection
 126
 127         We are using the Boehm conservative GC.  We might consider
 128         adopting other GC engines in the future, like the Intel ORP GC
 129         engine.  The Intel ORP GC engine as it provides a precise
 130         garbage collector engine, similar to what is available on the
 131         .NET environment.
 132
 133         <ul>
 134                 * Garbage collection list and FAQ:<br>
 135                   <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
 136
 137                 * "GC points in a Threaded Environment":<br>
 138                   <a href="http://research.sun.com/techrep/1998/abstract-70.html">
 139                   http://research.sun.com/techrep/1998/abstract-70.html</a>
 140
 141                 * "A Generational Mostly-concurrent Garbage Collector":
 142                   <a href="http://research.sun.com/techrep/2000/abstract-88.html">
 143                   http://research.sun.com/techrep/2000/abstract-88.html</a>
 144
 145                 * Details on The Microsoft .NET Garbage Collection Implementation:<br>
 146                   <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>
 147                   <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>
 148         </ul>
 149
 150 ** IO and threading
 151
 152         The ECMA runtime and the .NET runtime assume an IO model and a
 153         threading model that is very similar to the Win32 API.
 154
 155         Dick Porter has developed WAPI: the Mono abstraction layer
 156         that allows our runtime to execute code that depend on this
 157         behaviour.
 158
 159 ** Useful links
 160
 161         Paolo Molaro found a few interesting links:
 162
 163         <ul>
 164                 * On compilation of stack-based languages:<br>
 165                 <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
 166                 http://www.complang.tuwien.ac.at/projects/rafts.html</a>
 167
 168                 * A paper on fast JIT compilation of a stack-based language:<br>
 169                   <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
 170                   http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
 171
 172                 * Vmgen generates much of the code for efficient virtual machine (VM)
 173                   interpreters from simple descriptions of the VM instructions:<br>
 174                   <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
 175                   http://www.complang.tuwien.ac.at/anton/vmgen</a>
 176         </ul>
 177
 178 ** PInvoke
 179
 180         PInvoke is the mechanism we are using to wrap Unix API calls
 181         as well as talking to system libraries.
 182
 183         Initially we used libffi, but it was fairly slow, so we have
 184         reused parts of the JIT work to create efficient PInvoke
 185         trampolines.
 186
 187 ** Remoting
 188
 189         Mono has support for remoting and proxy objects, just like
 190         .NET does.  The runtime provides these facilities.
 191
 192 ** Porting
 193
 194         If you are interested in porting the Mono runtime to other
 195         platforms, you might find the pre-compiled <a
 196         href="archive/mono-tests.tar.gz">Mono regression test
 197         suite</a> useful to debug your implementation.
 198
 199 * COM and XPCOM
 200
 201         We plan on adding support for XPCOM on Unix and COM on Microsoft
 202         Windows later in our development process.
 203