X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;ds=sidebyside;f=web%2Fruntime;h=c2ecdf425a851c03e13d6d853e946e326253020f;hb=5eb836a1d21b5b678fa5e14a678194788869c9cf;hp=97f2e4eb8e6b990c3098ba2ac106d0a109defa16;hpb=73b849f9292403300cc5251b16ebe2736050aa7d;p=mono.git
diff --git a/web/runtime b/web/runtime
index 97f2e4eb8e6..c2ecdf425a8 100644
--- a/web/runtime
+++ b/web/runtime
@@ -1,59 +1,104 @@
* 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.
+
+ * mono: Our Just-in-Time and Ahead-of-Time code
+ generator for maximum performance.
+
+ * mint: The Mono interpreter. This is an
+ easy-to-port runtime engine.
+
+
+ We are using the Boehm conservative garbage collector.
+
+ The Mono runtime can be used as a stand-alone process, or it
+ can be embedded into applications (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 slides
+ here
+
+** Current JIT Engine: technical details (updated, June 28th, 2003)
- Our roadmap looks like this, this has been updated as of
- Jul 15, 2001:
+ We have re-written our JIT compiler. We wanted to support a
+ number of features that were missing:
+ * Ahead-of-time compilation.
- * Milestone 1: Done 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: Done 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: DoneDefine an lburg-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.
- 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:
+
+
+ * 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 (updated, Nov 16th, 2001)
+ * 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
+
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 lbrug.
- 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:
* A code generation interface for ANSI C
@@ -73,23 +124,11 @@
** 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 Garbage
- Collection.
-
- 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.
* Garbage collection list and FAQ:
@@ -111,9 +150,11 @@
** 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
@@ -139,7 +180,24 @@
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 Mono regression test
+ suite 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.
+