If class variable stored in stack and object in the managed heap then where the class properties get stored in C# .NET?

Hello @Jairaj Kushwaha ,

Thank you for raising a question about memory management in C# .NET. I built a small reproduce to visually demonstrate where class variables and object data are stored in memory.

Case 1: Stack vs Heap

[STACK] 'emp' reference address : 0xA5CDFEEBA8   <- Stack
[HEAP]  Employee object address : 0x2788A107470  <- Heap
Same address?                   : False

The reference variable emp lives on the Stack, while the actual Employee object lives on the Managed Heap at a completely different address.

Case 2: int (inline) vs string (separate) inside Employee

[HEAP]  Employee object address          : 0x2788A107470
[HEAP]  EmployeeName (string) address    : 0x2788000C1C0  <- different!
Same address?                            : False
[INLINE]   EmployeeId   = 101    (int, stored directly inside Employee object)
[SEPARATE] EmployeeName = "John" (string, stored separately on heap)

Not all properties are stored the same way. EmployeeId (int) is stored inside the Employee object, value types are stored inline. EmployeeName (string) is a separate object on the heap, the Employee object only holds a reference to it.

Below are Official Microsoft Documentations:

C# Classes

Properties (C# Programming Guide)

Hope this clears things up. If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Thank you.

reference types are allocated on the heap, value types are typically allocated on the stack, but boxing (cast as object) will allocate on the heap. if a class instance contains a value type, its allocated with the instance heap allocation in-place not separately. a class instance with a reference type (say a string), the pointer is in the instance allocation, and the the string instance is a separate heap allocation.

to better understand, if a variable is a value type, the variable references the actual value, which if a local variable is allocated on the stack. a static value type variable is allocated in the compile data space. reference type variables are a pointer to the object instance. again if a local variable, the pointer is allocated on the stack, if static the compiled data space.

at the compiler level, a local variable is a stack pointer address plus an offset. if the variable is a value type the computed address contains the value, if a reference type, its the pointer to the object instance.

To your question about object properties, they are all allocated on the heap, either as separate heap allocations or as part of the initial allocation.

Nice question you've asked. First of all, let me clear something up for you: classes that you mentioned are never on the stack; they are always on the heap. When you "instantiate" an object with a certain type, or in simpler terms, when you create an object like that "Employee EmployeeInstance = new Employee();", it will always be created on the heap; structs if initiated or instantiated in a local variable, on the other hands, are created on the stack. This is how .NET/C# does it.

Now we got that out of the way, let's address your actual question regarding where these properties are stored on .NET:

See when you don't define custom getter and setter methods for your property like that

public class Employee
{
public int EmployeeID
{
get
{
return myfield;
// stuff
}
set
{
myfield = value;
// stuff
}
}
}

the C# compiler will create a field for your property and emit code to read and assign that field in those set and get methods; that is basically the compiler's way to do the extra work of creating that "myfield" for you. The created field is just like the other fields in your class: the compiler names it like that "<YourPropertyName>k__BackingField" and adds it to your class layout. Take a look as this code below:

...
public int EmployeeID
	{
		[CompilerGenerated]
		get
		{
			return this.<EmployeeID>k__BackingField;
		}
		[CompilerGenerated]
		set
		{
			this.<EmployeeID>k__BackingField = value;
		}
	}
public Employee()
	{
	}

	[CompilerGenerated]
	[DebuggerBrowsable(DebuggerBrowsableState.Never)]
	private int <EmployeeID>k__BackingField;
}

This is how the compiler treats a property you define like that "EmployeeID{get; set;}" :)

The getter and the setter in the properties are just regular methods on the low level which the compiler names them like that "get_EmployeeID"; "set_EmployeeID":

Usually, the calls you make to these properties will be "inlined", and ultimately, your code will narrow down to a simple field assignment or memory read.

Hope that answers your question and others' :)