X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fruntime;h=0bd5ebc83a685affc7ebc19c2b3149ba138f2e35;hb=88860adf56a5a8fa324b4800d5d7309a2a6989b9;hp=5ea5e23b198e13c935a0cd93bec03b07063eff0c;hpb=983d92c25f124849761b0ece45f5fc6d1f60e4b1;p=mono.git diff --git a/web/runtime b/web/runtime index 5ea5e23b198..0bd5ebc83a6 100644 --- a/web/runtime +++ b/web/runtime @@ -1,70 +1,153 @@ -* The MonoNet runtime +* The Mono runtime - The MonoNet 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 contains the beginning of an image - loader and metadata access entry points. Since Beta2 has been - now released, it is possible to resume work using the ECMA - specs and testing with Beta2-generated executables. + We currently have two runtimes: - The runtime core will be implemented in C, in a library - "libMonoVES.so". + + + Currently both runtimes are missing garbage collection. We + are planning on using the ORP GC engine and deploy it by + middle January. + +* COM and XPCOM + + We plan on adding support for XPCOM on Unix and COM on Microsoft + Windows later in our development process. ** Executing MSIL/CIL images The code will load an executable and map the references to external assemblies to our own version of the assemblies on - GNU/Linux. + Linux. + + Our roadmap looks like this, this has been updated as of + Dec 18, 2001: - Our roadmap looks like this: + - * Milestone 6: non-Intel port of the Optimizing JIT - engine. - - A setup similar to the Kaffe JIT engine can be used to + 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 should work on Linux and Win32, although you - might need to install the CygWin32 development tools to get a - Unix-like compilation environment which is what we know how to - use. + will need to install the CygWin32 development tools to get a + Unix-like compilation environment (mostly we use GNU make in + a few of the makefiles). + +** JIT Engine (updated, Dec 18th, 2001) + + 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. + + 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 lbrug. + + A few papers that describe the instruction selector: + + ** 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. + 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. + + +** 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: + + + ** PInvoke - PInvoke will be supported, and will be used to wrap Unix API - calls, these in turn are required for reusing some of the - GNOME libraries that will reduce the work we have to do to - deliver a complete class library. + 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.