+++ /dev/null
-* The Mono runtime
-
- The Mono runtime engine is considered feature complete.
-
- It implements a Just-in-Time compiler engine for the CIL
- virtual machine, the class loader, the garbage collector,
- threading system and metadata access libraries.
-
- We currently have two runtimes:
-
- <ul>
- * <b>mono:</b> Our Just-in-Time and Ahead-of-Time code
- generator for maximum performance.
-
- * <b>mint:</b> The Mono interpreter. This is an
- easy-to-port runtime engine.
- </ul>
-
- We are using the Boehm conservative garbage collector.
-
- The Mono runtime can be used as a stand-alone process, or it
- can be <a href="embedded-api.html">embedded into applications</a> (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 <a
- href="http://primates.ximian.com/~lupus/slides/jit/">slides
- here</a>
-
-** Current JIT Engine: technical details (<b>updated, June 28th, 2003</b>)
-
- We have re-written our JIT compiler. We wanted to support a
- number of features that were missing:
-
- <ul>
- * Ahead-of-time compilation.
-
- The idea is to allow developers to pre-compile their code
- to native code to reduce startup time, and the working
- set that is used at runtime in the just-in-time compiler.
-
- Although in Mono this has not been a visible problem, we
- wanted to pro-actively address this problem.
-
- When an assembly (a Mono/.NET executable) is installed in
- the system, it would then be possible to pre-compile the
- code, and have the JIT compiler tune the generated code
- to the particular CPU on which the software is
- installed.
-
- This is done in the Microsoft.NET world with a tool
- called ngen.exe
-
- * Have a good platform for doing code optimizations.
-
- The design called for a good architecture that would
- enable various levels of optimizations: some
- optimizations are better performed on high-level
- intermediate representations, some on medium-level and
- some at low-level representations.
-
- Also it should be possible to conditionally turn these on
- or off. Some optimizations are too expensive to be used
- in just-in-time compilation scenarios, but these
- expensive optimizations can be turned on for
- ahead-of-time compilations or when using profile-guided
- optimizations on a subset of the executed methods.
-
- * Reduce the effort required to port the Mono code
- generator to new architectures.
-
- For Mono to gain wide adoption in the Unix world, it is
- necessary that the JIT engine works in most of today's
- commercial hardware platforms.
- </ul>
-
- The JIT engine implements a number of optimizations:
-
- <ul>
- * Opcode cost estimates (our architecture allows
- us to generate different code paths depending
- on the target CPU dynamically).
-
- * Inlining.
-
- * Constant folding, copy propagation, dead code elimination.
-
- 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.
-
- * SSA-based framework. Various optimizations are
- implemented on top of this framework
- </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>.
-
- The new JIT engines uses three intermediate representations:
- the source is the CIL which is transformed into a forest of
- trees; This is fed into a BURS instruction selector that
- generates the final low-level intermediate representation.
-
- The instruction selector is documented in the following
- papers:
-
- <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>
-
-** Garbage Collection
-
- We are using the Boehm conservative GC. We might consider
- adopting other GC engines in the future, like the Intel ORP GC
- engine. The Intel ORP GC engine as it provides a precise
- garbage collector engine, similar to what is available on the
- .NET environment.
-
- <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 developed WAPI: 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 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