* The Mono runtime
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:
* mono: The Just In Time compiler implemented
using a BURS instruction selector. We only support
x86 machines in the JIT engine at this point.
* mint: The Mono interpreter. This is an
easy-to-port runtime engine.
Currently we are using the Bohem 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
** Current JIT Engine (updated, July 8th, 2002)
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:
* Opcode cost estimates (our architecture allows
us to generate different code paths depending
on the target CPU dynamically).
* Inlining.
* Constant folding.
Although compilers typically do
constant folding, the combination of inlining with
constant folding gives some very good results.
* Linear scan register allocation. In the past,
register allocation was our achilles heel, but now
we have left this problem behind.
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 lbrug.
A few papers that describe the instruction selector:
** 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
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.
** 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:
** PInvoke
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 Mono regression test
suite 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.