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

[Zoltan.2.Varga@nokia.com]

				Hi,

> -----Original Message-----
> From: ext Dietmar Maurer [mailto:dietmar@ximian.com]
> Sent: 29. July 2002 17:23
> To: Varga Zoltan.2 (NMP/Budapest)
> Cc: Paolo Molaro; Mono List
> Subject: RE: [Mono-list] Announce: A .NET assembly -> native
> codegenerationtool (ala ngen for MONO)
> 
> 
> 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?

If the pointer returned by get_trampoline is put into a vtable, then get_unbox_trampoline() might need to be applied to it.
The separate trampoline is needed because the trampoline can't decide whenever this was a virtual call or not. After 
wrestling with virtual/non-virtual call detection for a _long_ time, I decided to move non-virtual call handling to a 
separate trampoline, and leave the virtual call handling to x86_magic_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.
> 

I will try that. 

					bye

						Zoltan

> - Dietmar
> 
>