doc/runtime

   1 * The MonoNet runtime
   2
   3         The MonoNet 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         Currently the runtime contains the beginning of an image
   9         loader and metadata access entry points.  Since Beta2 has been
  10         now released, it is possible to resume work using the ECMA
  11         specs and testing with Beta2-generated executables.
  12
  13         The runtime core will be implemented in C, in a library
  14         "libMonoVES.so".
  15
  16 ** Executing MSIL/CIL images
  17
  18         The code will load an executable and map the references to
  19         external assemblies to our own version of the assemblies on
  20         GNU/Linux.
  21
  22         Our roadmap looks like this:
  23
  24         <ul>
  25
  26                 * Milestone 1: Fully read and parse all CIL byte-codes
  27                   and metadata tokens (ie, a disassembler).
  28
  29                 * Milestone 2: Complete an interpreter for CIL byte
  30                   codes.  This interpreter can be used temporarly to
  31                   run CIL byte code on a system where no JIT is
  32                   available.
  33
  34                 * Milestone 3: IA32 translating-JIT engine.
  35
  36                 * Milestone 4: non-Intel port of the JIT engine.
  37
  38                 * Milestone 5: Optimizing JIT engine port for IA32.
  39
  40                 * Milestone 6: non-Intel port of the Optimizing JIT
  41                   engine.
  42         </ul>
  43
  44         A setup similar to the Kaffe JIT engine can be used to
  45         layout the code to support non-IA32 architectures.  Our work
  46         will be focused on getting a IA32 version running first.
  47
  48         The JIT engine should work on Linux and Win32, although you
  49         might need to install the CygWin32 development tools to get a
  50         Unix-like compilation environment.
  51
  52 ** Useful links
  53
  54         Paolo Molaro found a few interesting links:
  55
  56         <ul>
  57
  58                 * On compilation of stack-based languages:<br>
  59                 <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
  60                 http://www.complang.tuwien.ac.at/projects/rafts.html</a>
  61
  62                 * A paper on fast JIT compilation of a stack-based language:<br>
  63                   <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
  64                   http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
  65
  66                 * Vmgen generates much of the code for efficient virtual machine (VM)
  67                   interpreters from simple descriptions of the VM instructions:<br>
  68                   <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
  69                   http://www.complang.tuwien.ac.at/anton/vmgen</a>
  70
  71                 * Garbage collection list and FAQ:<br>
  72                   <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
  73         </ul>
  74
  75 ** Garbage Collection
  76
  77         We have decided to implement a generational tracing garbage
  78         collector, which is very similar to the one being used by
  79         .NET.  For an introduction to the garbage collection system
  80         used by Microsoft's CLR implementation, you can read this book
  81         on <a
  82         href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage
  83         Collection.</a>
  84
  85         Although using a conservative garbage collector like Bohem's
  86         would work, all the type information is available at runtime,
  87         so we can actually implement a better collector than a
  88         conservative collector.
  89
  90 ** PInvoke
  91
  92         PInvoke will be supported, and will be used to wrap Unix API
  93         calls, these in turn are required for reusing some of the
  94         GNOME libraries that will reduce the work we have to do to
  95         deliver a complete class library.