Sometimes, when I want to verify .net memory management behavior, I fire up ANTS Memory Profiler and run it on a test application just to see how memory management behaves.
So today I went and created this application
class Program
{
static void Main(string[] args)
{
A a = new A();
B b = new B { Pointer = a };
Console.WriteLine("One");
Console.ReadLine();
b.Pointer = null;
b = null;
Console.WriteLine("Two");
Console.ReadLine();
a = null;
Console.WriteLine("Three");
Console.ReadLine();
a = new A();
Console.WriteLine("Four");
Console.ReadLine();
}
}
class A
{
}
class B
{
public A Pointer;
}
The ReadLine calls allow me to hit the “Take Memory Snapshot” in profiler. Later I examined these snapshots, specially the one between One and Two. What would you expect, how many instances are alive at that point? I’d say one, the instance of class A (referenced by a).
However, the profiler was showing, surprisingly, two. According to it, both an instance of A and an instance of B, were still very much alive. This result surprised me. Even more surprisingly, after Four there was still an instance of B around. How is this possible? There are no references to b and it is pointing to null. A bug in Memory Profiler? Hardly possible.
Right before I was going to post a question on RedGate’s forum I decided to check the IL code. With .net reflector of course. Immediately I saw the reason for that odd behavior. Can you spot it?
.method private hidebysig static void Main(string[] args) cil managed { .entrypoint .maxstack 2 .locals init ( [0] class ConsoleApplication213.A a, [1] class ConsoleApplication213.B b, [2] class ConsoleApplication213.B b2) L_0000: nop L_0001: newobj instance void ConsoleApplication213.A::.ctor() L_0006: stloc.0 L_0007: newobj instance void ConsoleApplication213.B::.ctor() L_000c: stloc.2 L_000d: ldloc.2 L_000e: ldloc.0 L_000f: stfld class ConsoleApplication213.A ConsoleApplication213.B::Pointer L_0014: ldloc.2 L_0015: stloc.1 L_0016: ldstr "One" L_001b: call void [mscorlib]System.Console::WriteLine(string) L_0020: nop L_0021: call string [mscorlib]System.Console::ReadLine() L_0026: pop L_0027: ldloc.1 L_0028: ldnull L_0029: stfld class ConsoleApplication213.A ConsoleApplication213.B::Pointer L_002e: ldnull L_002f: stloc.1 L_0030: ldstr "Two" L_0035: call void [mscorlib]System.Console::WriteLine(string) L_003a: nop L_003b: call string [mscorlib]System.Console::ReadLine() L_0040: pop … }
For some reason, compiler decided to allocate two references for class B: local variables b and b2. When the instance of class B is created it is stored in b2. After the Pointer property is assigned the same reference is stored to b while b2 isn’t set to null. Then when b is set to null, the b2 is still very much alive and thus keeping the instances count for class B to 1 – even though b is null and there are no other C# variables for referencing instances of B.
Mystery solved. The lessons learned are that compiler might generate code one wouldn’t expect and that profiling memory isn’t always black and white. Those 50 shades of gray happen as well. IOW experience and good understanding of .net is a necessity.