I\'m curious to know how C# object references are represented in memory at runtime (in the .NET CLR). Some questions that come to mind are:
How much memory doe
.NET Heaps and Stacks This is a thorough treatment of how the stack and heap work.
C# and many other heap-using OOP languages in general reference-speak use Handles not Pointers for references in this context (C# is also capable of using Pointers!) Pointer analogies work for some general concepts, but this conceptual model breaks down for questions like this. See Eric Lippert's excellent post on this topic Handles are Not Addresses
It is not appropriate to say a Handle is the size of a pointer. (although it may coincidentally be the same) Handles are aliases for objects, it isn't required they be a formal address to an object.
In this case the CLR happens to use real addresses for the handles: From the above link:
...the CLR actually does implement managed object references as addresses to objects owned by the garbage collector, but that is an implementation detail.
So yes a handle is probably 4 bytes on a 32 bit architecture, and 8 bytes on a 64 byte architecture, but this is not a "for sure", and it is not directly because of pointers. It is worth noting depending on compiler implementation and the address ranges used some types of pointers can be different in size.
With all of this context you can probably model this by a pointer analogy, but it's important to realize Handles are not required to be addresses. The CLR could choose to change this if it wanted to in the future and consumers of the CLR shouldn't know any better.
A final drive of this subtle point:
This is a C# Pointer:
int* myVariable;
This is a C# Handle:
object myVariable;
They are not the same.
You can do things like math on pointers, that you shouldn't do with Handles. If your handle happens to be implemented like a pointer and you use it as if it were a pointer you are misusing the Handle in some ways that could get you in trouble later on.