Add Ada

[mono.git] / web / runtime

diff --git a/web/runtime b/web/runtime
index 97f2e4eb8e6b990c3098ba2ac106d0a109defa16..c2ecdf425a851c03e13d6d853e946e326253020f 100644 (file)
--- a/web/runtime
+++ b/web/runtime
@@ -1,59 +1,104 @@
 * The Mono runtime
 
 * The Mono runtime
 

-       The Mono runtime will implement the JIT engine (and a byte
-       code interpreter for quickly porting to new systems), the
-       class loader, the garbage collector, threading system and
-       metadata access libraries.
+       The Mono runtime engine is considered feature complete.

 
 

-       Currently the runtime has an image loader and metadata access
-       entry points.  The runtime comes with a simple interpreter
-       that can execute very simple programs. 
+       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.

 
 

-** Executing MSIL/CIL images
+       We currently have two runtimes:

 
 

-       The code will load an executable and map the references to
-       external assemblies to our own version of the assemblies on
-       Linux.
+       <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>)

 
 

-       Our roadmap looks like this, this has been updated as of
-       <b>Jul 15, 2001</b>:
+       We have re-written our JIT compiler. We wanted to support a
+       number of features that were missing:

 
        <ul>
 
        <ul>

+               * Ahead-of-time compilation.  

 
 

-               * Milestone 1: <b>Done</b> Fully read and parse all CIL byte-codes
-                 and metadata tokens (ie, a disassembler).  
+            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.

 
 

-               * Milestone 2: <b>Done</b> Complete an interpreter for CIL byte
-                 codes.  This interpreter can be used temporarly to
-                 run CIL byte code on a system where no JIT is
-                 available.
+            Although in Mono this has not been a visible problem, we
+            wanted to pro-actively address this problem.

 
 

-               * Milestone 3: <b>Done</b>Define an <i>lburg</i>-like
-                 instruction selector for the JITer for Intel.
-                 Although slower at JITing than a streaming JITer, it
-                 generates better code.  The same grammar can later
-                 be used for the stream jitter.
+            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. 

 
 

-               * Milestone 4: Implement JITer.  This is where our
-                 current efforts are focused on, the JITer is 60% ready.
+            This is done in the Microsoft.NET world with a tool
+            called ngen.exe

 
 

-               * Milestone 5: Port of the JITer to non IA32 systems.
+               * 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>
 
        </ul>
 

-       A setup similar to the Kaffe JIT engine will be used to
-       layout the code to support non-IA32 architectures.  Our work
-       will be focused on getting a IA32 version running first.  
+       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.

 
 

-       The JIT engine should work on Linux and Win32, although you
-       will need to install the CygWin32 development tools to get a
-       Unix-like compilation environment.
+                 Although compilers typically do
+                 constant folding, the combination of inlining with
+                 constant folding gives some very good results.

 
 

-** JIT Engine (<b>updated, Nov 16th, 2001</b>)
+               * Linear scan register allocation.  In the past,
+                 register allocation was our achilles heel, but now 
+                 we have left this problem behind.

 
 

-       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. 
+               * 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
 
        There are a couple of books that deal with this technique: "A
        Retargetable C Compiler" and "Advanced Compiler Design and


@@ -61,7 +106,13 @@
         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>.
 
         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:
+       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>
 
        <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>


@@ -73,23 +124,11 @@
 
 ** Garbage Collection
 
 
 ** Garbage Collection
 

-       We have decided to implement a generational tracing garbage
-       collector, which is very similar to the one being used by
-       .NET.  For an introduction to the garbage collection system
-       used by Microsoft's CLR implementation, you can read this book
-       on <a
-       href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage
-       Collection.</a>
-
-       Another consideration is to use the same interface that ORP
-       uses to its Garbage Collection system and reuse that GC system
-       instead of rolling our own, as the ORP system is pretty advanced
-       and is independent of the rest of ORP.
-
-       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.
+       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>
 
        <ul>
                * Garbage collection list and FAQ:<br>


@@ -111,9 +150,11 @@
 ** IO and threading
 
        The ECMA runtime and the .NET runtime assume an IO model and a
 ** 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.
+       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
 
 
 ** Useful links
 


@@ -139,7 +180,24 @@
        PInvoke is the mechanism we are using to wrap Unix API calls
        as well as talking to system libraries.
 
        PInvoke is the mechanism we are using to wrap Unix API calls
        as well as talking to system libraries.
 

-       We hvae implemented PInvoke through libffi, but we are likely
-       going to roll our own system as the runtime matures, specially
-       as the interpreter is approaching completion, and we move into
-       the JITer.
+       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.
+