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
200
201
202
203
204
|
* The Mono runtime
The Mono runtime engine is considered feature complete.
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.
We currently have two runtimes:
<ul>
* <b>mono:</b> Our Just-in-Time and Ahead-of-Time code
generator for maximum performance. This supports
x86, PowerPC and SPARC cpus.
* <b>mint:</b> The Mono interpreter. This is an
easy-to-port runtime engine.
</ul>
We are using the Boehm conservative garbage collector.
The Mono runtime can be used as a stand-alone process, or it
can be <a href="embedded-api.html">embedded into applications</a> (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 <a
href="http://primates.ximian.com/~lupus/slides/jit/">slides
here</a>
** Current JIT Engine: technical details (<b>updated, June 28th, 2003</b>)
We have re-written our JIT compiler. We wanted to support a
number of features that were missing:
<ul>
* Ahead-of-time compilation.
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.
Although in Mono this has not been a visible problem, we
wanted to pro-actively address this problem.
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.
This is done in the Microsoft.NET world with a tool
called ngen.exe
* 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.
</ul>
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, copy propagation, dead code elimination.
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.
* SSA-based framework. Various optimizations are
implemented on top of this framework
</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>.
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:
<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>
** Garbage Collection
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.
<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 developed WAPI: 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.
|
