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.
We currently have two runtimes:
Currently we are using the Boehm conservative garbage collector.
The Mono runtime can be used as a stand-alone process, or it can
be embedded into applications (see the
documentation in mono/samples/embed for more details).
Embedding the Mono runtime allows applications to be extended in
C# while reusing all of the existing C and C++ code.
Paolo Molaro did a presentation on the current JIT engine and the new JIT engine. You can find his slides here
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.
The JIT engine implements a number of optimizations:
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.
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.
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.
Paolo Molaro found a few interesting links:
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.
Mono has support for remoting and proxy objects, just like
.NET does. The runtime provides these facilities.
If you are interested in porting the Mono runtime to other
platforms, you might find the pre-compiled
Mono regression test suite
useful to debug your implementation.
We plan on adding support for XPCOM on Unix and COM on Microsoft Windows later in our development process.