c#: What happens in a variable in memory?

Question

If I have this variable:

string name;

will it be allocated a location in the memory? Or it will only get allocated memory when I initialize it to a specific value? I.e.,

string name = "Jack";

For example, consider the following code:

for (int i = 0; i < 20; i++) {
    Run();
}

private void Run() {
    int age = 20;
}

What will happen to the age value in the memory? Will it be removed from memory in each execution of the Run method? Or will it stay in the memory after the code is executed and removed after the program that uses it close?

Answer 1

string name;

If this is your only statement, the compiler will probably optimize and remove it. Without optimizations, this will be a reference to null.

string name = "Jack";

This will create a memory allocation in the heap to store the string itself. It will also generate a pointer in your stack with the address of the allocated heap memory. Upon exiting the method and stack popped, the allocated memory in the heap will no longer have a reference and can be flagged for garbage collection.

Your 20 iterations will generate 20 stack allocations, each of which would have the value 20 in the stack with nothing generated in the heap. Upon exiting the method, the stack would be popped and the data lost.

Answer 2

For any .NET value type variable like int, bool, double, etc.; the memory allocation happens as soon as you declare it and when you assign value to it, the value is just updated in memory.

For reference types including string, on the other hand, only an address is assigned in memory which creates a reference to the actual memory location where the current value is stored (similar to pointers in C/C++).

So, in your example, age will be created in memory as soon as the int age is run and then it's value will be set to 20 when the age = 20 gets executed.

It'll be assigned a new memory location each time the Run() method is executed.

Answer 3

If you have this code:

void Main()
{
    string name;
}

Then, when compiled (in LINQPad) with compiler optimisation you get the following IL:

IL_0000:  ret

And without optimisation:

IL_0000:  nop         
IL_0001:  ret         

There is no memory allocated for this declaration - just a NOP operation as a placeholder in the IL for the unoptimised code.

When your program is this:

void Main()
{
    string name = "Jack";
}

Then you compiler optimised code is:

IL_0000:  ret

The compiler simply ignores the unused variable.

The unoptimised code generates this:

IL_0000:  nop         
IL_0001:  ldstr       "Jack"
IL_0006:  stloc.0     // name
IL_0007:  ret         

Obviously the unoptimised code is more explanatory, so I'll only show unoptimsed code from now on unless I explicitly say otherwise.

Now let's make the code do something more interesting.

void Main()
{
    string name = "Jack";
    Console.WriteLine(name);
}

This produces:

IL_0000:  nop         
IL_0001:  ldstr       "Jack"
IL_0006:  stloc.0     // name
IL_0007:  ldloc.0     // name
IL_0008:  call        System.Console.WriteLine
IL_000D:  nop         
IL_000E:  ret         

What's interesting is if we change this code to this:

void Main()
{
    int answer = 42;
    Console.WriteLine(answer);
}

We get this:

IL_0000:  nop         
IL_0001:  ldc.i4.s    2A 
IL_0003:  stloc.0     // answer
IL_0004:  ldloc.0     // answer
IL_0005:  call        System.Console.WriteLine
IL_000A:  nop         
IL_000B:  ret         

The code is virtually the same as the string example.

The ldstr call is getting a reference to a string literal (which is store in the String Pool on the Large Object Heap (not the normal heap which is the Small Object Heap) and pushing it on the evaluation stack.

The ldc.i4.s is pushing a reference to the number 42 on to the evaluation stack.

Then, in both cases, stloc.0 is storing the value on top of the evaluation stack into the zeroth local memory location for the method.

Then, in both cases again, ldloc.0 is loading the value from the zeroth local memory location and putting it on the evaluation stack.

You can probably imagine what the compiler might do if it were optimising this code.

Finally the System.Console.WriteLine is made.

Now let's look at that pesky string code in more detail.

I said that it's stored in the Intern Pool. Let's check that.

Take this code:

void Main()
{
    string name = "Jack";
    Console.WriteLine(String.IsInterned(name));
}

It produces:

IL_0000:  nop         
IL_0001:  ldstr       "Jack"
IL_0006:  stloc.0     // name
IL_0007:  ldloc.0     // name
IL_0008:  call        System.String.IsInterned
IL_000D:  call        System.Console.WriteLine
IL_0012:  nop         
IL_0013:  ret

And it outputs Jack to the console. It can only do that if System.String.IsInterned returns an interned string.

Take this program to show the opposite:

void Main()
{
    string name = String.Join("", new [] { "Ja", "ck" });
    Console.WriteLine(String.IsInterned(name));
}

It pushed out null to the console - meaning that the string name isn't interned so in this case name is stored on the heap (Small Object Heap).

Let's look at your second bit of code:

void Main()
{
    for (int i = 0; i < 20; i++)
    {
        Run();
    }
}

private void Run()
{
    int age = 20;
}

If we look at optimised IL then the Run method looks like this:

Run:
IL_0000:  ret        

The unoptimised IL is this:

Run:
IL_0000:  nop         
IL_0001:  ldc.i4.s    14 
IL_0003:  stloc.0     // age
IL_0004:  ret 

And, like my earlier example with an int, it is loading the literal value 20 (or 14 in hex) onto the evaluation stack and then immediately storing it in the local memory for the method, and then returns. And hence it is repeating using the same memory 20 times for the local variable age.

Answer 4

In your first example (uninitialized variable), it will not allocate any memory since it won't generate any MSIL. It will be the same as no code at all. If you initialize it, memory will be allocated in the current method's stack.

Second case, the age variable will be allocated in the stack for each method call and should be released when each method call exits.