web/runtime

   1 * The Mono runtime
   2
   3         The Mono runtime will implement the JIT engine (and a byte
   4         code interpreter for quickly porting to new systems), the
   5         class loader, the garbage collector, threading system and
   6         metadata access libraries.
   7
   8         We currently have two runtimes:
   9
  10         <ul>
  11                 * <b>mint:</b> The Mono interpreter.  This is an
  12                   easy-to-port runtime engine.
  13
  14                 * <b>mono:</b> The Just In Time compiler implemented
  15                   using a BURS instruction selector
  16         </ul>
  17
  18         Currently both runtimes are missing garbage collection.  We
  19         are planning on using the ORP GC engine and deploy it by
  20         middle January.
  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 should work 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, Dec 18th, 2001</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         There are a couple of books that deal with this technique: "A
  70         Retargetable C Compiler" and "Advanced Compiler Design and
  71         Implementation" are good references.  You can also get a
  72         technical description of <a
  73         href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
  74
  75         A few papers that describe the instruction selector:
  76
  77         <ul>
  78                 * <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>
  79
  80
  81                 * <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>
  82
  83         </ul>
  84
  85 ** Garbage Collection
  86
  87         We will be using the Intel ORP GC engine as it provides a precise
  88         garbage collector engine, similar to what is available on the
  89         .NET environment.
  90
  91         Although using a conservative garbage collector like Bohem's
  92         would work, all the type information is available at runtime,
  93         so we can actually implement a better collector than a
  94         conservative collector.
  95
  96         <ul>
  97                 * Garbage collection list and FAQ:<br>
  98                   <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
  99
 100                 * "GC points in a Threaded Environment":<br>
 101                   <a href="http://research.sun.com/techrep/1998/abstract-70.html">
 102                   http://research.sun.com/techrep/1998/abstract-70.html</a>
 103
 104                 * "A Generational Mostly-concurrent Garbage Collector":
 105                   <a href="http://research.sun.com/techrep/2000/abstract-88.html">
 106                   http://research.sun.com/techrep/2000/abstract-88.html</a>
 107
 108                 * Details on The Microsoft .NET Garbage Collection Implementation:<br>
 109                   <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>
 110                   <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>
 111         </ul>
 112
 113 ** IO and threading
 114
 115         The ECMA runtime and the .NET runtime assume an IO model and a
 116         threading model that is very similar to the Win32 API.
 117
 118         Dick Porter has been working on the Mono abstraction layer
 119         that allows our runtime to execute code that depend on this
 120         behaviour.
 121
 122 ** Useful links
 123
 124         Paolo Molaro found a few interesting links:
 125
 126         <ul>
 127                 * On compilation of stack-based languages:<br>
 128                 <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
 129                 http://www.complang.tuwien.ac.at/projects/rafts.html</a>
 130
 131                 * A paper on fast JIT compilation of a stack-based language:<br>
 132                   <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
 133                   http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
 134
 135                 * Vmgen generates much of the code for efficient virtual machine (VM)
 136                   interpreters from simple descriptions of the VM instructions:<br>
 137                   <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
 138                   http://www.complang.tuwien.ac.at/anton/vmgen</a>
 139         </ul>
 140
 141 ** PInvoke
 142
 143         PInvoke is the mechanism we are using to wrap Unix API calls
 144         as well as talking to system libraries.
 145
 146         Initially we used libffi, but it was fairly slow, so we have
 147         reused parts of the JIT work to create efficient PInvoke trampolines.