In this post we finally get on to how basic generic methods are implemented in IL. First of all, we should briefly cover how a generic method is declared in IL.<\/p>\n
Declaring a generic method<\/b><\/p>\n
The basic syntax for a generic method is fairly straightfoward. The following C# generic method definition: <\/p>\n
public static void GenericMethod<T1, T2>(T1 arg0, T2 arg1){ \/* ... *\/ }<\/pre>\n corresponds to the following IL method definition: <\/p>\n
.method public static void GenericMethod<T1, T2>(!!T1 arg0, !!T2 arg1){ \/* ... *\/ }<\/pre>\n The !!<\/code> in front of the generic type references tell the IL compiler that these should be interpreted as generic method parameters, a single !<\/code> in front of a type name refers to a generic parameter of a containing class. You can also refer to generic parameters by their ordinal, so !!0<\/code> is the same as !!T1<\/code> and !!1<\/code> is the same as !!T2<\/code>.<\/p>\nCalling methods on generic types<\/b><\/p>\n
To start with, we’ll look at how you call a virtual method on an instance of a generic type. So, given the following generic method definition: <\/p>\n
.method public static string CallToString<T>(!!T obj) {\n \/\/ ????\n callvirt instance string [mscorlib]System.Object::ToString()\n ret\n}<\/pre>\n what should go in place of the ????<\/code> to push the object we want to call ToString<\/code> on onto the stack? Remember, T<\/code> can either be a reference or value type, but callvirt<\/code> only accepts a heap object reference as the this<\/code> pointer. Well, as it turns out, box<\/code> doesn’t have to be used on a value type; trying to box<\/code> a reference type turns into a no-op. This should do what we want: <\/p>\n.method public static string CallToString<T>(!!T obj) {\n ldarg.0\n box !!T\n callvirt instance string [mscorlib]System.Object::ToString()\n ret\n}<\/pre>\n If T<\/code> is a reference type, then callvirt<\/code> uses the same object reference loaded by ldarg.0<\/code>. If T<\/code> is a value type, then ldarg.0<\/code> copies the value type value onto the stack, box !!T<\/code> turns it into an object reference, and callvirt<\/code> uses that as the this<\/code> pointer. All well and good.<\/p>\nThrowing in a mutable spanner<\/b><\/p>\n
However, once again, mutableness rears its ugly head. What if you wanted to call IIncrementable.Increment<\/code> in a generic method? In other words, the equivalent of this C# method: <\/p>\npublic static void CallIncrement<T>(T obj) where T : IIncrementable {\n \/\/ ....\n obj.Increment(1);\n \/\/ ....\n}<\/pre>\n (as a side point, generic type constraints are specified in IL like so: .method public static void CallIncrement<(IIncrementable) T>(!!T obj)<\/code>)<\/p>\nIf T<\/code> is IncrementableClass<\/code>, this should increment the Value<\/code> field of the object reference stored in the obj<\/code> parameter. If T<\/code> is IncrementableStruct<\/code> the incremented value type should be copied back to the obj<\/code> parameter.<\/p>\nFortunately, there is an IL command to help us do this: unbox.any<\/code>, which performs the reverse of box<\/code> – copies a boxed value type instance back onto the stack. Again, this operation turns into a no-op (specifically, a castclass<\/code>) if the type argument is a reference type. This leads to the following IL to call the IIncrementable.Increment<\/code> method on a generic type: <\/p>\nldarg.0\nbox !!T\ndup\nldc.i4.1\ncallvirt instance void IIncrementable::Increment(int32)\nunbox.any !!T\nstarg 0<\/pre>\n Phew! And, just to confirm, here’s the stack transition if T<\/code> is IncrementableClass<\/code>: <\/p>\nldarg.0 \/\/ O[IncrementableClass]\nbox !!T \/\/ O[IncrementableClass]\ndup \/\/ O[IncrementableClass],O[IncrementableClass]\nldc.i4.1 \/\/ O[IncrementableClass],O[IncrementableClass],int32\ncallvirt... \/\/ O[IncrementableClass]\nunbox.any !!T \/\/ O[IncrementableClass]\nstarg 0<\/pre>\n And for IncrementableStruct<\/code>: <\/p>\nldarg.0 \/\/ IncrementableStruct\nbox !!T \/\/ O[IncrementableStruct]\ndup \/\/ O[IncrementableStruct],O[IncrementableStruct]\nldc.i4.1 \/\/ O[IncrementableStruct],O[IncrementableStruct],int32\ncallvirt... \/\/ O[IncrementableStruct]\nunbox.any !!T \/\/ IncrementableStruct\nstarg 0<\/pre>\n And this is only for calling a virtual method on an object in a method parameter! Versions of this will have to be constructed for calling it on a local variable, on a value that’s going to be used in another method parameter, on an array element… Furthermore, this is quite wasteful of both IL code size and run-time performance. Not only will we have to output variations of this code for every method call made on an instance of a generic type, but if T<\/code> is a value type, then we are copying the entire value type instance twice, and generating a heap object that will need to be garbage collected, simply to call a method on it. There must be a better way.<\/p>\nFinding the MethodTable<\/code><\/b><\/p>\nLets take a step back. The only reason we have to box the value type instance is to generate a MethodTable<\/code> pointer as part of the heap object that the virtual method call can use. But, if it’s a value type, we already know the correct table to use at compile time, as value types are all sealed. What if we could specify the MethodTable<\/code> to use without<\/em> having to box the instance?<\/p>\nThis is where the constrained.<\/code> prefix instruction comes in (note the dot at the end). This specifies which MethodTable<\/code> the following callvirt<\/code> should use if one isn’t already provided by the this<\/code> pointer. It also modifies the callvirt<\/code> to take a this<\/code> of type &<\/code> rather than O<\/code>; if the constrained type is a reference type, the &<\/code> is a pointer to an object reference (so it’s a void**<\/code> in C parlance), if it’s a value type, it’s a pointer to a value type instance (for the same reasons that call<\/code> on a value type takes a &<\/code>).<\/p>\nSo, the call to obj.Increment(1)<\/code> turns into the following IL: <\/p>\nldarga 0\nldc.i4.1\nconstrained. !!T\ncallvirt instance void IIncrementable::Increment(int32)<\/pre>\n More specifically, the constrained callvirt<\/code> instruction has the following behaviour: <\/p>\n\n- If
T<\/code> is a reference type, the this<\/code> &<\/code> is dereferenced to an O<\/code> and passed as the this<\/code> to a standard callvirt<\/code><\/li>\n- If
T<\/code> is a value type and implements the method directly, the this<\/code> &<\/code> is passed unmodified to a standard call<\/code>, using the method implementation specified in the MethodTable<\/code> for T<\/code><\/li>\n- If
T<\/code> is a value type and does not implement the method directly, then the this<\/code> &<\/code> is dereferenced, boxed, and the resulting O<\/code> is passed as the this<\/code> to a standard callvirt<\/code> (this only applies to virtual methods on System.Object<\/code> that are not directly overridden by the value type)<\/li>\n<\/ul>\nThis eliminates both the copying of value types and the IL code bloat for performing a virtual method call on an instance of a generic type.<\/p>\n
Also note that constrained<\/code> doesn’t have to be used with a generic type; it can be used in non-generic methods as well: <\/p>\n.method public static void CallIncrement(\n valuetype IncrementableStruct obj) {\n ldarga 0\n ldc.i4.1\n constrained. IncrementableStruct\n callvirt instance void IIncrementable::Increment(int32)\n \/\/ ...\n}<\/pre>\n although it can’t be used to directly call value type methods (as call<\/code> works perfectly well for that): <\/p>\nconstrained. IncrementableStruct\ncallvirt instance void IncrementableStruct::Increment(int32)\n\nIL Error: [offset 0x0000001B] Callvirt on a value type method.<\/pre>\n<\/p>\nTo wrap up<\/b><\/p>\n