Hi,> -----Original Message----- > From: ext Dietmar Maurer [mailto:[EMAIL PROTECTED]] > 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, [EMAIL PROTECTED] 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 > > _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
