1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
* The Mono runtime
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.
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
The code will load an executable and map the references to
external assemblies to our own version of the assemblies on
Linux.
Our roadmap looks like this, this has been updated as of
<b>Dec 18, 2001</b>:
<ul>
* Milestone 1: <b>Done</b> Fully read and parse all CIL byte-codes
and metadata tokens (ie, a disassembler).
* 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.
* Milestone 3: <b>Done</b>Define an <i>lburg</i>-like
instruction selector for the JITer for Intel.
* 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>
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 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.
** Useful links
Paolo Molaro found a few interesting links:
<ul>
* On compilation of stack-based languages:<br>
<a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
http://www.complang.tuwien.ac.at/projects/rafts.html</a>
* A paper on fast JIT compilation of a stack-based language:<br>
<a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
* Vmgen generates much of the code for efficient virtual machine (VM)
interpreters from simple descriptions of the VM instructions:<br>
<a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
http://www.complang.tuwien.ac.at/anton/vmgen</a>
</ul>
** PInvoke
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.
** 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.
|
