[Mono-devel-list] [PATCH] VTable layout
Lluis Sanchez
lluis at ximian.com
Tue Mar 23 12:26:49 EST 2004
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
More information about the Mono-devel-list
mailing list