[Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO)

[Dietmar Maurer]

On Mon, 2002-07-29 at 12:34, Paolo Molaro wrote:
> On 07/29/02 Dietmar Maurer wrote:
> >         1. It does not work with exceptions: The current code is
> >            incorrect because it does not save/restore the LMF when
> >            calling precompiled methods - but saving/restoring the LMF
> >            would lead to serious performance problems.
> 
> As long as the native code doesn't handle exceptions, the only info
> needed is registering the method code address and size, there is no need
> to save/restore the LMF, right? I saw the code that uses objdump, so
> maybe this is already handled.
> Actually, if this turns out to work, we may want to use it also for the
> internalcalls.

Ok, if we trust such code we can use the objdump hack. Although
restoring the registers is still a big hack.

> 
> > > 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. 
> > 
> > So IMO we should first check if we gain anything by using gcc, and of
> > course we need a solution for the exception problem? 
> 
> I think the approach of using gcc is certainly interesting even if the
> first snapshot has limitations.
> The primary purpouse of ngen-ed assemblies is to reduce startup and JIT
> costs (microsoft itself documents ngen-assemblies being slower code-wise
> than jitted code...). Of course, performance is an bonus:-), but I'm
> very impressed with the first snapshot.
> 
> The gain in mcs compilation times, for example, seems to match
> pretty well with the jit overhead as measured with mono --profile.
> And, of course, mcs is not a good benchmark for native code quality.
> 
> Of the current limitations, the .ovf opcodes seems only a matter of
> (boring) programming, mostly. The exception handling stuff is certainly
> harder and if done using the C++ exception tables, it will
> require porting efforts between different compilers. However, I just
> checked and methods with exception tables are less than 7% in mcs and
> less than 2% in corlib, so even if 5% of the methods still need to be
> jitted, it's not a big problem.

good news ;-)

> 
> My main concern with using gcc is that we might not be able to constrain
> the gcc optimizer to obey the CLR rules (Zoltan notes the problem with
> division by 0, for example). Using the JIT to output the code would give
> us better control on such issues, but researching these issues is the
> only way to find out if the concept works:-)

So I think everybody agrees that it would be nice to have a native code
generator, so integrating that code into the sources should be the goal.
All I am concerned about it to avoid code duplication, which makes it
hard to maintain that code. I would like to share as much code as
possible with the JIT.

Unfortunately the current patch is much to large to integrate. What we
need is a bunch of smaller patches which we can integrate into our
codebase.
 
- Dietmar