C# 4.0: Dynamic’s compiler tricks

So, I was curious today. I had some code that used dynamic and was wondering what the heck the compiler was doing on the back end. So, I wrote up a very small test program, and tore into it using Reflector. The version of Reflector I used still only decompiles to C# 3, so it happily displayed all of the inner workings to me without trying to hide any of it. Here is my test program:

static void Main(string[] args)
{
    dynamic foo = "bar";
    int meep = foo.Length;
}

Nice and simple, it shouldn’t look too bad… Well, the compiler generates a static container class that it uses to keep track of some things, and it names everything using names that can’t possibly collide with the programmer’s code. So, instead of showing you code that could make your eyes bleed, I took the liberty of renaming everything and inserting new lines to help readability, the result was:

static class CallSiteContainer
{
    public static CallSite<Func<CallSite, object, int>> convertSite { get; set; }
    public static CallSite<Func<CallSite, object, object>> getLengthSite { get; set; }
}

private static void Main(string[] args)
{
    object foo = "bar";

    if (CallSiteContainer.convertSite == null)
        CallSiteContainer.convertSite = CallSite<Func<CallSite, object, int>>
            .Create(new CSharpConvertBinder(typeof(int), 
		CSharpConversionKind.ImplicitConversion, false));

    if (CallSiteContainer.getLengthSite == null)
        CallSiteContainer.getLengthSite = CallSite<Func<CallSite, object, object>>
            .Create(new CSharpGetMemberBinder("Length", typeof(Program),
                new CSharpArgumentInfo[] {
                    new CSharpArgumentInfo(CSharpArgumentInfoFlags.None, null)
                }));

    int meep = CallSiteContainer.convertSite.Target.Invoke(
        CallSiteContainer.convertSite,
        CallSiteContainer.getLengthSite.Target.Invoke(
            CallSiteContainer.getLengthSite, foo));
}

So, the first thing to notice is that the compiler is generating a static inner container class that holds the call sites for the operation so that it doesn’t have to keep creating them over and over. A call site is a point where we interact with a dynamic object, we have two here, the get on .Length and the conversion of the result of that gets to an integer. Also notice that foo is actually just an object when things are all said and done, the compiler just wraps all interactions with it.

The generic parameter on the CallSite class ends up determining the signature of the call site’s Invoke method. Since the CallSiteContainer.convertSite ends up being the equivalent of the folling lambda, it takes Func<callsite> to say that it takes a CallSite, and the object to convert as parameters, then returns an integer.

Func<object, int> convertSite = obj => (int)obj;

It just takes whatever object and tries to convert it to an int. The other call site is a bit trickier, because you cannot express it as a lambda at compile time, but you could generate one at runtime, look here for details on that. What we do know is that the CallSiteContainer.getLengthSite fetches the value of the Length property or field off of whatever object it is handed. It’s not yet clear to me why the CSharpGetMemberBinder takes the Program type and that CSharpArgumentInfo array, but it probably has something to do with how the DLR caches the code it generates. This whole thing is powered by the DLR, which does all the code generation and caching transparently on the back end. So be thankful for IronPython being around to kick all of this stuff off ;).

When we want to actually perform our operation, getting the Length of foo, and assigning it to meep, it just Invokes both of the call sites, passing the output of the getLengthSite to the convertSite, then taking the result of that and giving it to meep. I don’t know why each call site is passed itself as the first parameter, but after that comes what would be passed into the lambda equivalent of each call site. When the call site is Invoked, it is passed in so it can be updated to handle new cases that it hasn’t seen before, then all of the arguments that would have been passed into the lambda equivalent follow.

Well, that’s about it, all of this generated code isn’t too complex, it’s just pretty wordy. Looking at this and DynamicObject, it occurs to me that implementing Ruby style Mixins, methodMissing, and send shouldn’t be too hard. If you feel like I left anything out, please point it out in the comments.

EDIT: Incorporated information that Curt provided in the comments.