Where are ref value type parameters stored for asynchronous method calls in Microsoft's CLR?

Question

I understand that this is an implementation detail. I'm actually curious what that implementation detail is in Microsoft's CLR.

Now, bear with me as I did not study CS in college, so I might have missed out on some fundamental principles.

But my understanding of the "stack" and the "heap" as implemented in the CLR as it stands today is, I think, solid. I'm not going to make some inaccurate umbrella statement such as "value types are stored on the stack," for example. But, in most common scenarios -- plain vanilla local variables, of value type, either passed as parameters or declared within the method and not contained inside a closure -- value type variables are stored on the stack (again, in Microsoft's CLR).

I guess what I'm unsure of is where ref value type parameters come in.

Originally what I was thinking was that, if the call stack looks like this (left = bottom):

A() -> B() -> C()

...then a local variable declared within the scope of A and passed as a ref parameter to B could still be stored on the stack--couldn't it? B would simply need the memory location where that local variable was stored within A's frame (forgive me if that isn't the right terminology; I think it's clear what I mean, anyway).

I realized this couldn't be strictly true, though, when it occurred to me that I could do this:

delegate void RefAction<T>(ref T arg);

void A()
{
    int x = 100;

    RefAction<int> b = B;

    // This is a non-blocking call; A will return immediately
    // after this.
    b.BeginInvoke(ref x, C, null);
}

void B(ref int arg)
{
    // Putting a sleep here to ensure that A has exited by the time
    // the next line gets executed.
    Thread.Sleep(1000);

    // Where is arg stored right now? The "x" variable
    // from the "A" method should be out of scope... but its value
    // must somehow be known here for this code to make any sense.
    arg += 1;
}

void C(IAsyncResult result)
{
    var asyncResult = (AsyncResult)result;
    var action = (RefAction<int>)asyncResult.AsyncDelegate;

    int output = 0;

    // This variable originally came from A... but then
    // A returned, it got updated by B, and now it's still here.
    action.EndInvoke(ref output, result);

    // ...and this prints "101" as expected (?).
    Console.WriteLine(output);
}

So in the example above, where is x (in A's scope) stored? And how does this work? Is it boxed? If not, is it subject to garbage collection now, despite being a value type? Or can the memory immediately be reclaimed?

I apologize for the long-winded question. But even if the answer is quite simple, maybe this will be informative to others who find themselves wondering the same thing in the future.

Answer 1

Look at the code generated with reflector to find out. My guess is that an anonymous class containing x is generated, like when you use closures (lambda expressions that reference variables in the current stack frame). Forget about this and read the other answers.

Answer 2

The CLR is completely out of the loop on this, it is the job of the JIT compiler to generate the appropriate machine code to get an argument passed by reference. Which is an implementation detail in itself, there are different jitters for different machine architectures.

But the common ones do it exactly the way a C programmer does it, they pass a pointer to the variable. That pointer is passed in a CPU register or on the stack frame, depending on how many arguments the method takes.

Where the variable lives doesn't matter, a pointer to a variable in the stack frame of the caller is just as valid as a pointer to member of a reference type object that's stored on the heap. The garbage collector knows the difference between them, by virtue of the pointer value, adjusting the pointer if necessary when it moves an object.

Your code snippet invokes magic inside the .NET framework that's required to make marshaling calls from one thread to another work. This is the same kind of plumbing that makes Remoting works. To make such a call, a new stack frame has to be created on the thread where the call is performed. The remoting code uses the type definition of the delegate to know what that stack frame should look like. And it can deal with arguments passed by reference, it knows that it needs to allocate a slot in the stack frame to store the pointed-to variable, i in your case. The BeginInvoke call initializes the copy of the i variable in the remoted stack frame.

The same thing happens on the EndInvoke() call, the results are copied back from the stack frame in the threadpool thread. Key point is that there isn't actually a pointer to the i variable, there's a pointer to the copy of it.

Not so sure this answer is very clear, having some understanding of how CPUs work and a bit of C knowledge so the concept of a pointer is crystal can help a lot.