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

[Dietmar Maurer]

On Mon, 2002-07-29 at 15:30, Zoltan.2.Varga@nokia.com wrote:
> If there is concern whenever this will be the 'real' MONO ngen, I would gladly name it something else. Any ideas?
> 
> > 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.
> 
> I plan on maintaining the code whenever its integrated into MONO CVS or not. The current patch is 600 lines long 
> (this includes the context added by diff) + the two new files (ngen-runtime.{c,h}). It includes the following:
> 
>   ngen-runtime.{c,h} - this does the loading and linking in of native assemblies
>   appdomain.h        - adds a new field to MonoJitInfo
>   assembly.{c,h}     - adds a callback function which will be called when an assembly is loaded
>   exception.c        - adds exception handling for native methods (hackish)
>   mono.c             - adds additional command line arguments + installs the native assembly loading callback
>   trampoline.c       - adds a new trampoline which can be called by the native methods + adds a new argument to
>                        x86_magic_trampoline so it can read the receiver off the stack
>   
>   There are two bug fixes/improvements in the patch:
>    reflection.c      - speed up mono_type_get_object which seems to be called a lot
>    trampoline.c      - the arch_get_trampoline function sometimes returns a pointer to JIT generated code instead of a 
> 			     trampoline. This is wrong if the returned pointer is put into a vtable. This is not happening 				     currently, but I think it is by coincidence not by design :).
> 

Your patch contains many changes, an I would prefer to integrate them
step by step. For example the get_type speedup code is totally
unrelated. Or that callback function on assembly load.

I don't understand some comments, for example why is it wrong if the
get_trampoline returns final code instead of the trampoline? Any why do
we need another trampoline?

IMO we cant integrate things like the (hackish) exception handling, or
anything that make maintaining/porting more complex. Everything else can
be integrated.

Maybe you can use a LMF before calling gcc generated code (simply call
them like internal calls). It would be interesting to test if
performance gets really worse. If not we can use that approach and dump
the ugly exception hack.

- Dietmar