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

[Paolo Molaro]

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.

> > 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.

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:-)

lupus

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