[Mono-list] Announce: A .NET assembly -> native code generationtool (ala ngen for MONO)
Thu, 1 Aug 2002 13:42:10 +0200
> -----Original Message-----
> From: ext Dietmar Maurer [mailto:firstname.lastname@example.org]
> Sent: 01. August 2002 7:56
> To: Fergus Henderson
> Cc: Miguel de Icaza; Varga Zoltan.2 (NMP/Budapest); Mono List
> Subject: Re: [Mono-list] Announce: A .NET assembly -> native code
> generationtool (ala ngen for MONO)
> On Thu, 2002-08-01 at 04:39, Fergus Henderson wrote:
> > On 29-Jul-2002, Dietmar Maurer <email@example.com> wrote:
> > > On Sun, 2002-07-28 at 06:03, Miguel de Icaza wrote:
> > > > Zoltan wrote:
> > > >
> > > > > The first version of my ngen clone for MONO is
> available at:
> > > > >
> > > > > http://www.nexus.hu/vargaz2
> > Excellent.
> > > > This announcement is of course really exciting. I have
> only taken a
> > > > very superficial look so far at the code generator, but
> the approach is
> > > > a very interesting idea. I will let Dietmar and Paolo
> comment further
> > > > on it.
> > I think this approach is a really good approach.
> > > > What I wanted to look into was to use the JIT to
> generate code that
> > > > would end up in a library, basically reusing the JIT,
> but turning on all
> > > > the optimizations for this.
> > >
> > > This approach would also avoid much code duplication.
> > This approach is what MS did. This approach sucks.
> > You just won't get good performance that way.
> Sure, but I also has some advantages. For example it works with
> exceptions and garbage collection. I have no idea how we can
> include GC
> support with the gcc approach.
A conservative garbage collector, like the Boehm collector can work with gcc code if the code is "GC-safe", i.e. it always
keeps pointers to the beginning or interior of all live objects. An example of non-gc safe code is:
a[i - 5] = 0;
When confronted with such code an optimizing compiler might decide to transform it to something like (a-5)[i], which means
there are no pointers left pointing to a, so it will be garbage collected. A relevant paper is here:
Unfortunately, based on a web search on google about 'gcc gc-safe', it looks like the code generated by gcc is not always
gc-safe. It looks like the projects which use Boehm-GC like to live dangerously...
It might be possible to generated GC safe code based on the ideas of the above paper.
Of course, the gcc approach does not work at all with non-conservative collectors, since these like to know which registers/
memory locations contain pointers.
As a final remark, I throught (and still thinking about) writing a GCC front end for IL similar to gcj. My biggest problem
with this approach is that I would like to target the MONO runtime, and reuse MONO code in the front end. In contrast, gcj
is self contained: it includes its own runtime library (libgcj) and targets that.
> - Dietmar