mono/doc/runtime

* 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> 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>

	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: technical details (<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

	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.