| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169 |
- * 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:
- <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>
- Currently we are using the Bohem conservative garbage
- collector.
- 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).
- 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 (<b>updated, July 8th, 2002</b>)
- 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:
- <ul>
- * 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.
- </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
- 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 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.
|