[Mono-list] mcs compiles on linux. Now what?

Paolo Molaro lupus@ximian.com
Thu, 7 Mar 2002 20:08:48 +0100

Yes, you read that right, I managed to compile mcs on linux.
Here it is what you need if you want to try it at home:

latest cvs corlib, mcs and runtime.

Configure the runtime with the --with-gc option, since the compiler will
use loads of memory while running. You can use the copy found in the
libgc module or, better, install the development libraries for libgc
from your distribution vendor: on debian it's as easy as:

	apt-get install libgc6-dev

You'll need to compile mcs with the interpreter:

mint /somewhere/mcs.exe  --target exe -o mcs.exe assign.cs attribute.cs 
driver.cs cs-parser.cs cs-tokenizer.cs tree.cs location.cs class.cs 
codegen.cs const.cs constant.cs decl.cs delegate.cs enum.cs ecore.cs 
expression.cs genericparser.cs interface.cs literal.cs modifiers.cs 
namespace.cs parameter.cs report.cs rootcontext.cs statement.cs 
statementCollection.cs support.cs typemanager.cs

(it should be all in one line).
The sources of mcs I used are from a couple of days ago, but the latest
could work as well, you just need to change in interfaces.cs
the two spots where DefineType() and DefineNestedType(): change the "null"
to "(Type)null" and the compilation should complete.

Note: it took from 14 to 20 minutes to build on my PIII 1.1 with the
debugging mint, you may want to compile the runtime with CFLAGS=-O2
and set DEBUG_INTERP to 0 in interp.c to save a couple of minutes.

The bad news is that the compiled mcs crashes, because some field tokens
are wrong and this confuses the runtime (we still don't have a verifier,
hint, hint).

So, where do we go from here?
We need three things:
1) make the JIT work with the Boehm garbage collector (it has weird
crashes, specially when running mcs) so that we can compile mcs faster
and track the down bugs faster.
2) optimize some classes in corlib that are slowing down the compilation
(more on this later)
3) try compiling your own programs/libraries with mcs on linux and
report the failures and specially if the generated program works: bonus
points to anyone that can reproduce bugs with small test cases.
Flood bugzilla with compilation bug reports. Help us reporting the
OS/runtime you used and tell us if the program compiles fine in windows
(with mcs) but not on linux. You can also start compiling our test suite
(in mono/mono/tests/*.cs and mcs/tests/test-*.cs) and report which
program compiled but failed to run. Your help with these tests is very
important now.

If you want to optimize corlib, here is some profile data:

System.Collections.Hashtable::Find() takes more than 40% of the compile
time (it's called 522682 times). Hashtable::KeyEquals() takes about 25%
of the running time and is called 26880116 times.
This suggest we may be using bad hash functions or that the hashtable
doesn't resize correctly, since the average compare per lookup is
greater than 5 (it should be about 1). So check the sources for
bad GetHashCode() implementations, create tests to check that the
hashtable behaves correctly when expanding.
Another abvious culprit is String.IndexOf(string) and it's BoyerMoore
helper function: help replace it with a fast implementation.



lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better