-* The MonoNet runtime
+* The Mono runtime
- The MonoNet runtime will implement the JIT engine (and a byte
- code interpreter for quickly porting to new systems), the
- class loader, the garbage collector, threading system and
- metadata access libraries.
+ The Mono runtime implements a JIT engine for the CIL virtual
+ machine (as well as a byte code interpreter, this is to
+ quickly port it to new systems), the class loader, the garbage
+ collector, threading system and metadata access libraries.
- Currently the runtime contains the beginning of an image
- loader and metadata access entry points. Since Beta2 has been
- now released, it is possible to resume work using the ECMA
- specs and testing with Beta2-generated executables.
+ We currently have two runtimes:
- The runtime core will be implemented in C, in a library
- "libMonoVES.so".
+ <ul>
+ * <b>mono:</b> The Just In Time compiler implemented
+ using a BURS instruction selector. We only support
+ x86 machines in the JIT engine at this point.
+
+ * <b>mint:</b> The Mono interpreter. This is an
+ easy-to-port runtime engine.
+ </ul>
-** Executing MSIL/CIL images
+ Currently we are using the Bohem conservative garbage
+ collector.
- The code will load an executable and map the references to
- external assemblies to our own version of the assemblies on
- GNU/Linux.
+ The Mono runtime can be used as a stand-alone process, or it
+ can be <a href="embedded-api">embedded into applications</a> (see
+ the documentation in mono/samples/embed for more details).
- Our roadmap looks like this:
+ Embedding the Mono runtime allows applications to be extended
+ in C# while reusing all of the existing C and C++ code.
- * Milestone 1: Fully read and parse all CIL byte-codes
- and metadata tokens (ie, a disassembler).
+ Paolo Molaro did a presentation on the current JIT engine and
+ the new JIT engine. You can find his <a
+ href="http://primates.ximian.com/~lupus/slides/jit/">slides
+ here</a>
- * Milestone 2: Complete an interpreter for CIL byte
- codes. This interpreter can be used temporarly to
- run CIL byte code on a system where no JIT is
- available.
+** Current JIT Engine (<b>updated, July 8th, 2002</b>)
- * Milestone 3: IA32 translating-JIT engine.
+ The JIT engine uses a code-generator generator approach for
+ compilation. Given the properties of CIL byte codes, we can
+ take full advantage of a real instruction selector for our
+ code generator.
- * Milestone 4: non-Intel port of the JIT engine.
+ The JIT engine implements a number of optimizations:
- * Milestone 5: Optimizing JIT engine port for IA32.
+ <ul>
+ * Opcode cost estimates (our architecture allows
+ us to generate different code paths depending
+ on the target CPU dynamically).
+
+ * Inlining.
- * Milestone 6: non-Intel port of the Optimizing JIT
- engine.
+ * Constant folding.
- A setup similar to the Kaffe JIT engine can be used to
- layout the code to support non-IA32 architectures. Our work
- will be focused on getting a IA32 version running first.
+ Although compilers typically do
+ constant folding, the combination of inlining with
+ constant folding gives some very good results.
- The JIT engine should work on Linux and Win32, although you
- might need to install the CygWin32 development tools to get a
- Unix-like compilation environment which is what we know how to
- use.
+ * Linear scan register allocation. In the past,
+ register allocation was our achilles heel, but now
+ we have left this problem behind.
+ </ul>
+
+ There are a couple of books that deal with this technique: "A
+ Retargetable C Compiler" and "Advanced Compiler Design and
+ Implementation" are good references. You can also get a
+ technical description of <a
+ href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
+
+ A few papers that describe the instruction selector:
+
+ <ul>
+ * <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>
+
+
+ * <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>
+
+ </ul>
+
+** New JIT engine.
+
+ We are working on a new JIT engine. The new JIT engine
+ focuses on portability and in two intermediate representations
+ that simplify the development of optimizations. This together
+ with the Ahead-of-Time compilation will allow developers to
+ deploy applications that match the speed of natively compiled code.
** Garbage Collection
- We have decided to implement a generational tracing garbage
- collector, which is very similar to the one being used by
- .NET. For an introduction to the garbage collection system
- used by Microsoft's CLR implementation, you can read this book
- on <a
- 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
- Collection.</a>
+ Currently we are using the Boehm conservative GC. Although our plans
+ are to move to the Intel ORP GC engine, our plans on a next generation
+ dual-JIT engine have to be taken into account.
+
+ We will be using the Intel ORP GC engine as it provides a precise
+ garbage collector engine, similar to what is available on the
+ .NET environment.
Although using a conservative garbage collector like Bohem's
would work, all the type information is available at runtime,
so we can actually implement a better collector than a
conservative collector.
+ <ul>
+ * Garbage collection list and FAQ:<br>
+ <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
+
+ * "GC points in a Threaded Environment":<br>
+ <a href="http://research.sun.com/techrep/1998/abstract-70.html">
+ http://research.sun.com/techrep/1998/abstract-70.html</a>
+
+ * "A Generational Mostly-concurrent Garbage Collector":
+ <a href="http://research.sun.com/techrep/2000/abstract-88.html">
+ http://research.sun.com/techrep/2000/abstract-88.html</a>
+
+ * Details on The Microsoft .NET Garbage Collection Implementation:<br>
+ <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>
+ <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>
+ </ul>
+
+** IO and threading
+
+ The ECMA runtime and the .NET runtime assume an IO model and a
+ threading model that is very similar to the Win32 API.
+
+ Dick Porter has been working on the Mono abstraction layer
+ that allows our runtime to execute code that depend on this
+ behaviour.
+
+** Useful links
+
+ Paolo Molaro found a few interesting links:
+
+ <ul>
+ * On compilation of stack-based languages:<br>
+ <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
+ http://www.complang.tuwien.ac.at/projects/rafts.html</a>
+
+ * A paper on fast JIT compilation of a stack-based language:<br>
+ <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
+ http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
+
+ * Vmgen generates much of the code for efficient virtual machine (VM)
+ interpreters from simple descriptions of the VM instructions:<br>
+ <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
+ http://www.complang.tuwien.ac.at/anton/vmgen</a>
+ </ul>
+
** PInvoke
- PInvoke will be supported, and will be used to wrap Unix API
- calls, these in turn are required for reusing some of the
- GNOME libraries that will reduce the work we have to do to
- deliver a complete class library.
+ PInvoke is the mechanism we are using to wrap Unix API calls
+ as well as talking to system libraries.
+
+ Initially we used libffi, but it was fairly slow, so we have
+ reused parts of the JIT work to create efficient PInvoke trampolines.
+
+** Remoting
+
+ Mono has support for remoting and proxy objects, just like
+ .NET does. The runtime provides these facilities.
+
+** Porting
+
+ If you are interested in porting the Mono runtime to other
+ platforms, you might find the pre-compiled <a
+ href="archive/mono-tests.tar.gz">Mono regression test
+ suite</a> useful to debug your implementation.
+
+* COM and XPCOM
+
+ We plan on adding support for XPCOM on Unix and COM on Microsoft
+ Windows later in our development process.
+
projects / mono.git / blobdiff