[Mono-devel-list] Embedding mcs into ASP.NET.

[Andreas Nahr]

Hi,

I've been looking into the subject (converting mcs into a library) for quite
some time now, but unfortunatelly didn't find any time to do any real
development work on that topic.
However I at least want to make a quick comment on the topic, although
Miguel probably isn't going to like it ;)

Lets start with the bad news: Imho the design of mcs is seriously flawed, at
least to use it as a shared component.
Besides the organic structure of the code the biggest problem is that huge
parts of the core are simply static. While this is no serious problem for a
single instanced-application (.exe) it surely is for a library.
The latest changes try to mitigate that by using some "Reset" function which
should delete static data (effectively you are trying to do your own
memorymanagement at this point - which at this level is a very bad idea),
which in turn will completely stop to work in ANY multithreaded setting.
To mitigate this you would have to create Application-domains (rather
similar to spawning a new process), which in turn will make the code much
slower, have a much higher memory overhead and will likely produce more
threading issues.

The current situation isn't much better if you look at how calling mcs from
e.g. System.dll works today: We input the data into system, that creates
strings from the data, concats these, spawns an entirely new process with
mcs (which includes all UI stuff), hands over the strings via the OS to the
new process, mcs is going to analyze the strings using its arguments,
creates internal values from these, runs, converts its results back to
strings (well mostly they are directly stored this way internally), The
caller waits for the mcs process to finish in a non-event-based manner,
receives a string via the OS, analyzes the string by using regex (or other)
methods and then copies the result back in databuffers.

I think this makes it clear that this is far from perfect. A nice way would
be:
Put arguments into system, new CSharpCompiler() receives arguments,
syncroniously or asyncroniuosly run, returns results as objects.

This is what mcs should imho look like:
* Separate mcs into mcs.exe and mcs.dll where mcs.exe is basically the
command line parser and ui and mcs.dll (CSharpCompiler.dll) contains the
compiler itself
* Make mcs.dll have a nice managed interface that is based on objects (not
pushing strings around)
* To archive these the parts in mcs that are static now need to be converted
to non-static (which makes sense either way because it should make the code
faster and the static is completely useless at that point)
* That means also to remove any console access from the compiler because it
is going to have VERY annoying effects when used as library.
* Make sure that you can call the compiler in a multithreaded
environment/setting
* Bonus if the compiler can run async and sync (if the points above are
implemented this should not be a big deal)

In fact we have one huge advantage over MS.Net: an entirely managed
compiler. Howerver we are not using that advantage at all, because we
require all the same "native interop" = spawning new OS-processes as a
native compiler, which is not how it should be.

P.S. As we know Future CPUs will contain multiple cores so we really should
look into getting it multithreaded

----- Original Message ----- 
From: "Ben Maurer" <bmaurer at ximian.com>
To: "Zoltan Varga" <vargaz at gmail.com>
Cc: "Miguel de Icaza" <miguel at novell.com>; <mono-devel-list at ximian.com>
Sent: Friday, April 01, 2005 9:55 PM
Subject: Re: [Mono-devel-list] Embedding mcs into ASP.NET.


> On Fri, 2005-04-01 at 13:42 +0200, Zoltan Varga wrote:
>> The memory management inside ref.emit is not very embedding friendly
>> right
>> now, i.e. it is highly possible that there are memory leaks so memory
>> usage will
>> probably increase with each compilation.
>
> The mcs embedding stuff would be a great test case for this. When Miguel
> told me about the mcs embedding stuff I actually pondered about using it
> as a leakage/race stress test for appdomains. My idea was:
>
> Start up N appdomains in N threads and give each a different task for
> compilation. Run this in a loop M times.
>
> Since mcs touches so many parts of the runtime, I think this would be a
> great stress test.
>
> -- Ben
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>