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

[Jonathan Gilbert]

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.

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