3 The Mono runtime engine is considered feature complete.
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.
9 We currently have two runtimes:
12 * <b>mono:</b> The Just In Time compiler implemented
13 using a BURS instruction selector. We only support
14 x86 machines in the JIT engine at this point.
16 * <b>mint:</b> The Mono interpreter. This is an
17 easy-to-port runtime engine.
20 We are using the Boehm conservative garbage collector.
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).
26 Embedding the Mono runtime allows applications to be extended
27 in C# while reusing all of the existing C and C++ code.
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
34 ** Current JIT Engine: technical details (<b>updated, July 8th, 2002</b>)
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
41 The JIT engine implements a number of optimizations:
44 * Opcode cost estimates (our architecture allows
45 us to generate different code paths depending
46 on the target CPU dynamically).
52 Although compilers typically do
53 constant folding, the combination of inlining with
54 constant folding gives some very good results.
56 * Linear scan register allocation. In the past,
57 register allocation was our achilles heel, but now
58 we have left this problem behind.
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>.
67 A few papers that describe the instruction selector:
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>
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>
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.
87 We are using the Boehm conservative GC. We might consider
88 adopting other GC engines in the future, like the Intel ORP GC
89 engine. The Intel ORP GC engine as it provides a precise
90 garbage collector engine, similar to what is available on the
94 * Garbage collection list and FAQ:<br>
95 <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
97 * "GC points in a Threaded Environment":<br>
98 <a href="http://research.sun.com/techrep/1998/abstract-70.html">
99 http://research.sun.com/techrep/1998/abstract-70.html</a>
101 * "A Generational Mostly-concurrent Garbage Collector":
102 <a href="http://research.sun.com/techrep/2000/abstract-88.html">
103 http://research.sun.com/techrep/2000/abstract-88.html</a>
105 * Details on The Microsoft .NET Garbage Collection Implementation:<br>
106 <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>
107 <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>
112 The ECMA runtime and the .NET runtime assume an IO model and a
113 threading model that is very similar to the Win32 API.
115 Dick Porter has developed WAPI: the Mono abstraction layer
116 that allows our runtime to execute code that depend on this
121 Paolo Molaro found a few interesting links:
124 * On compilation of stack-based languages:<br>
125 <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
126 http://www.complang.tuwien.ac.at/projects/rafts.html</a>
128 * A paper on fast JIT compilation of a stack-based language:<br>
129 <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
130 http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
132 * Vmgen generates much of the code for efficient virtual machine (VM)
133 interpreters from simple descriptions of the VM instructions:<br>
134 <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
135 http://www.complang.tuwien.ac.at/anton/vmgen</a>
140 PInvoke is the mechanism we are using to wrap Unix API calls
141 as well as talking to system libraries.
143 Initially we used libffi, but it was fairly slow, so we have
144 reused parts of the JIT work to create efficient PInvoke
149 Mono has support for remoting and proxy objects, just like
150 .NET does. The runtime provides these facilities.
154 If you are interested in porting the Mono runtime to other
155 platforms, you might find the pre-compiled <a
156 href="archive/mono-tests.tar.gz">Mono regression test
157 suite</a> useful to debug your implementation.
161 We plan on adding support for XPCOM on Unix and COM on Microsoft
162 Windows later in our development process.