Flush

[mono.git] / web / runtime

diff --git a/web/runtime b/web/runtime
index 97f2e4eb8e6b990c3098ba2ac106d0a109defa16..da16f189387ff062b86e09b7de1f0787c7db15f4 100644 (file)
--- a/web/runtime
+++ b/web/runtime
@@ -1,13 +1,23 @@
 * 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 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.

 
 

-       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. 
+       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, but we working on incorporating the ORP GC engine. 

 
 ** Executing MSIL/CIL images
 
 
 ** Executing MSIL/CIL images
 


@@ -16,7 +26,7 @@
        Linux.
 
        Our roadmap looks like this, this has been updated as of
        Linux.
 
        Our roadmap looks like this, this has been updated as of

-       <b>Jul 15, 2001</b>:
+       <b>Dec 18, 2001</b>:

 
        <ul>
 
 
        <ul>
 


@@ -30,12 +40,12 @@
 
                * Milestone 3: <b>Done</b>Define an <i>lburg</i>-like
                  instruction selector for the JITer for Intel.
 
                * 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.

 
 

-               * Milestone 4: Implement JITer.  This is where our
-                 current efforts are focused on, the JITer is 60% ready.
+               * Milestone 4: <b>Done</b> Implement JITer.  This is where our
+                 current efforts are focused on, the JITer currently runs
+                 all of the code we have tested on it.  The major limitation
+                 is that our class libraries are not complete, and hence not
+                 every application can be ran.

 
                * Milestone 5: Port of the JITer to non IA32 systems.
        </ul>
 
                * Milestone 5: Port of the JITer to non IA32 systems.
        </ul>


@@ -44,17 +54,38 @@
        layout the code to support non-IA32 architectures.  Our work
        will be focused on getting a IA32 version running first.  
 
        layout the code to support non-IA32 architectures.  Our work
        will be focused on getting a IA32 version running first.  
 

-       The JIT engine should work on Linux and Win32, although you
+       The JIT engine works on Linux and Win32, although you

        will need to install the CygWin32 development tools to get a
        will need to install the CygWin32 development tools to get a

-       Unix-like compilation environment.
+       Unix-like compilation environment (mostly we use GNU make in 
+       a few of the makefiles).

 
 

-** JIT Engine (<b>updated, Nov 16th, 2001</b>)
+** 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 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
        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


@@ -71,20 +102,25 @@
 
        </ul>
 
 
        </ul>
 

+** Future plans
+
+       We are evaluating the future directions for the JIT engine:
+       both from our needs (optimizations like inlining, better register allocation,
+       instruction scheduling, and porting to other CPUs).
+
+       We have not yet decided how we will evolve the JIT engine.  We
+       might just upgrade our current architecture, and provide optimizations as
+       an extra layer.
+

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

 
 

-       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.
+       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,
 
        Although using a conservative garbage collector like Bohem's
        would work, all the type information is available at runtime,


@@ -111,9 +147,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 been working on the Mono abstraction layer
+       that allows our runtime to execute code that depend on this
+       behaviour.

 
 ** Useful links
 
 
 ** Useful links
 


@@ -139,7 +177,23 @@
        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.
+