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