[Mono-devel-list] [PATCH] VTable layout

[Lluis Sanchez]

On dc, 2004-03-24 at 03:10, Jonathan Gilbert wrote:
> I don't understand how this is possible. Consider a method which takes a
> reference to an object of type 'A'. Unbeknownst to the JIT, this type will
> later on be used with remoting. It is not yet used. The JIT emits this
> method and directly inlines the calls to A's non-virtual methods. That is,
> since they cannot be overridden, the calls point directly at the target
> methods' JIT output.

Calls to methods of types derived from MarshalByRefObject (the only ones
that can be proxies) are handled in a special way by the JIT, so it will
never inline such calls.

Lluis.

> 
> All is good and fine, and the caller passes various instances of 'A' to
> this method. Then, it sets up a remoting session and obtains a reference to
> an instance of 'A' on the server. It passes this instance to the method.
> 
> How are the calls to the method going to proxied?
> 
> Jonathan
> 
> At 11:27 AM 23/03/2004 -0500, you wrote:
> >They seem to get their own wrapper methods that are not affected by the
> >patch.
> >
> >The test with proxies that was working still works.
> >
> >-- Ben
> >
> >On Tue, 2004-03-23 at 17:52, Jonathan Gilbert wrote:
> >> An issue was raised earlier that I don't recall seeing a response to: How
> >> does this affect transparent proxies for remoting?
> >> 
> >> Jonathan
> >> 
> >> At 09:21 PM 22/03/2004 +0100, you wrote:
> >> >On dg, 2004-03-21 at 17:27, Paolo Molaro wrote:
> >> >> On 03/20/04 Ben Maurer wrote:
> >> >> > A changelog:
> >> >> > 
> >> >> >       * class.c -- do not insert non-virtual methods in the vtable 
> >> >> >       * icall.c, mono-debug-debugger.c, object.c: if method->slot
> == -1,
> >> >> >         that means the method is non-virtual. This never would have
> >> >> >         happened before.
> >> >> > 
> >> >> > No regressions occur on the mini regression tests, the mono tests, nor
> >> >> > the corlib tests.
> >> >> 
> >> >> If lluis can confirm there are no regressions, please commit.
> >> >
> >> >The patch seems to be ok. I found no regressions.
> >> >
> >> >Lluis.
> >> >
> >> >> 
> >> >> > Index: icall.c
> >> >> > ===================================================================
> >> >> > RCS file: /cvs/public/mono/mono/metadata/icall.c,v
> >> >> > retrieving revision 1.434
> >> >> > diff -u -r1.434 icall.c
> >> >> > --- icall.c	17 Mar 2004 23:59:47 -0000	1.434
> >> >> > +++ icall.c	20 Mar 2004 20:42:14 -0000
> >> >> > @@ -2549,9 +2549,12 @@
> >> >> >  		}
> >> >> >  		
> >> >> >  		match = 0;
> >> >> > -		if (g_hash_table_lookup (method_slots, GUINT_TO_POINTER
> >> (method->slot)))
> >> >> > -			continue;
> >> >> > -		g_hash_table_insert (method_slots, GUINT_TO_POINTER (method->slot),
> >> method);
> >> >> > +		if (method->slot != -1) {
> >> >> > +			if (g_hash_table_lookup (method_slots, GUINT_TO_POINTER
> >> (method->slot)))
> >> >> > +				continue;
> >> >> > +			g_hash_table_insert (method_slots, GUINT_TO_POINTER
> >> (method->slot), method);
> >> >> > +		}
> >> >> > +		
> >> >> 
> >> >> After this patch is committed and tested, you could try to use a
> >> >> MonoBitset instead of the hashtable: it may give a measurable speedup.
> >> >> Also, looking at the code, it's not clear to me what would happen for
> >> >> properties which override just the get or the set method: maybe in that
> >> >> case we need to consider both the setter and the getter slots in the
> >> >> hashtable. Could you write a test case for that and try to break the
> >> >> current code?
> >> >> Thanks.
> >> >> 
> >> >> lupus
> >> >
> >> >_______________________________________________
> >> >Mono-devel-list mailing list
> >> >Mono-devel-list at lists.ximian.com
> >> >http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >> >
> >> >
> >> _______________________________________________
> >> Mono-devel-list mailing list
> >> Mono-devel-list at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >_______________________________________________
> >Mono-devel-list mailing list
> >Mono-devel-list at lists.ximian.com
> >http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list