+ The JIT engine works on Linux and Win32, although you
+ 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 (<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>
+
+** 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
+
+ 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.
+
+ 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.
+
+ <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 been working on the Mono abstraction layer
+ that allows our runtime to execute code that depend on this
+ behaviour.