Reference types live on the heap, value types live on the stack
I may be a somewhat useful abstraction to have a mental image of what's going on behind the scenes. But neither is true in any currently shipping version of the JIT compilers. Which perhaps is the crux of the issue, actual allocation location is a JIT compiler implementation detail.
There are at least six places where a value type value can live with mainstream (x86 and x64) jitters:
- in a stack frame, put there by a local variable declaration or a method call
- in a CPU register, a very common optimization performed by the JIT in the Release build. And used to pass arguments to a method, the first two x86, four for x64. And local variables when possible
- on the FPU stack, used by the x86 jitter for floating point values
- on the GC heap, when the value is part of a reference type
- on the loader heap of the AppDomain, when the variable is declared static
- in thread-local storage when the variable has the [ThreadStatic] attribute.
Reference type objects are commonly allocated on the GC heap. But I know of one specific exception, interned strings produced from literals in the source code are allocated in the AppDomain's loader heap. This completely behaves like an object at runtime, except that it isn't linked in to the GC heap, the collector simply cannot see it.
Addressing your code snippet:
- yes, "a" is likely to be stored on the GG heap
- "x" is always passed in a CPU register on x86 and x64. "y" will be in a CPU register on x64, the stack on x86.
- "c" is likely to not exist at all, removed by the JIT compiler because the code has no effect.
Quoting Jon Skeet from his famous blog about how and where reference and value types are stored in a .Net application:
The memory slot for a variable is stored on either the stack or the heap. It depends on the context in which it is declared:
- Each local variable (ie one declared in a method) is stored on the stack. That includes reference type variables - the variable itself is on the stack, but remember that the value of a reference type variable is only a reference (or null), not the object itself. Method parameters count as local variables too, but if they are declared with the ref modifier, they don't get their own slot, but share a slot with the variable used in the calling code. See my article on parameter passing for more details.
- Instance variables for a reference type are always on the heap. That's where the object itself "lives".
- Instance variables for a value type are stored in the same context as the variable that declares the value type. The memory slot for the instance effectively contains the slots for each field within the instance. That means (given the previous two points) that a struct variable declared within a method will always be on the stack, whereas a struct variable which is an instance field of a class will be on the heap.
- Every static variable is stored on the heap, regardless of whether it's declared within a reference type or a value type. There is only one slot in total no matter how many instances are created. (There don't need to be any instances created for that one slot to exist though.) The details of exactly which heap the variables live on are complicated, but explained in detail in an MSDN article on the subject.
https://docs.microsoft.com/en-us/archive/blogs/ericlippert/the-stack-is-an-implementation-detail-part-one
The whole "reference types on the heap, value types on the stack" is not only a bad way to look at it, but it's wrong too.