What is the difference between value types and reference types in C#? Explain copy semantics, equality, where they are stored, and why "value types live on the stack" is only partly true.

1. Object layout on the managed heap

Every reference-type object on 64-bit .NET has:

[ object header (8 bytes) ][ MethodTable pointer (8 bytes) ][ fields ... ]
             ^ sync block index / hash code / lock info

• The MethodTable pointer identifies the type (used for virtual dispatch, casting, GC).
• The minimum object size is 24 bytes even with no fields.
• A reference to the object points at the MethodTable pointer, not the header.

A struct has no header and no MethodTable pointer when stored inline — just its fields (plus padding for alignment). That is why an array of 1,000,000 ints is ~4 MB, while 1,000,000 boxed ints are ~24 MB plus 8 MB of references.

2. How the stack and registers hold values

When the JIT compiles a method, value-type locals are assigned to registers where possible, otherwise to slots in the method's stack frame. Struct locals may be promoted (each field gets its own register — "struct promotion") if the struct is small and not address-exposed. Taking a ref to a struct, passing it by ref, or calling non-inlined methods on it can prevent promotion, so it lands in memory.

Reference-type locals are just pointer-sized values in registers or stack slots; the GC scans them as roots at safe points to find live objects.

3. Why "stack vs heap" is an implementation detail

The C# specification only defines semantics: value types have copy semantics, reference types have reference semantics. Where memory lives is a runtime choice:

• The compiler moves captured locals into closure classes (heap).
• async methods move locals into state machine structs that are boxed to the heap on the first real suspension.
• yield iterators move locals into iterator classes.
• Escape analysis (.NET 9 started stack-allocating boxes and small non-escaping objects; .NET 10 extended it to small arrays and delegates) can put reference-type objects on the stack when the JIT proves they never escape the method.

Eric Lippert's well-known point: describing value types as "stack types" teaches the wrong mental model. Teach semantics first.

4. ref struct — the true stack-only types

Span<T>, ReadOnlySpan<T>, Utf8JsonReader and your own ref structs must live on the stack because they may contain managed pointers (ref fields) into stack memory or the middle of objects. The compiler enforces:

• No boxing, no conversion to object or interfaces (C# 13 allows implementing interfaces and generic allows ref struct constraints, but still no boxing).
• No fields of ref struct type inside classes or normal structs.
• No capture in lambdas, and no use across await or yield (relaxed in C# 13 when not crossing the suspension point).

5. Struct equality internals

ValueType.Equals(object):

1. Checks the other object is the same type.
2. If the struct has no reference fields and no padding/float quirks ("can compare bits"), it does a fast memcmp of the bytes.
3. Otherwise it uses reflection to compare each field — orders of magnitude slower, and it boxes.

ValueType.GetHashCode historically hashed only the first non-null field, which can produce terrible hash distribution in dictionaries (e.g. a struct whose first field is a constant). That is why structs used as keys should implement IEquatable<T> and GetHashCode with HashCode.Combine, or be record structs, which generate both.

6. Copy costs and defensive copies

Copying a struct is a memcpy of its size. For small structs this is cheaper than a heap allocation plus GC. For large structs, copies on every assignment, argument and return add up, and the compiler creates defensive copies when calling non-readonly members on readonly locations (readonly fields, in parameters). Marking the struct readonly removes them.

7. Arrays of structs vs arrays of classes

Point[] (struct):   [X][Y][X][Y][X][Y]...         contiguous, cache-friendly
Point[] (class):    [ref][ref][ref]... -> objects scattered across the heap

Iterating an array of structs reads sequential memory, which CPU prefetchers love; iterating references causes a potential cache miss per element. This is the core of data-oriented design and why high-performance .NET code (game engines, parsers, ML.NET) uses structs in arrays and spans.

Try it yourself

1. Use ObjectLayoutInspector (NuGet) to print the layout of a small class and the equivalent struct.
2. Measure GC.GetAllocatedBytesForCurrentThread() before and after creating 1,000,000 class instances vs filling a struct array.
3. Benchmark a struct dictionary key with and without IEquatable<T>.
4. Mutate a struct inside foreach and inside a List<T> via the indexer to see copy semantics bite.

namespace Types;

public readonly record struct GeoPoint(double Lat, double Lon);   // value type, value equality
public sealed class Order { public decimal Total { get; set; } }  // reference type

public struct MutablePoint { public int X; public int Y; }

public static class ValueVsReference
{
    public static void Main()
    {
        // Copy semantics
        var a = new MutablePoint { X = 1, Y = 2 };
        var b = a;          // copy
        b.X = 99;
        Console.WriteLine(a.X);                 // 1

        var o1 = new Order { Total = 10m };
        var o2 = o1;        // same object
        o2.Total = 99m;
        Console.WriteLine(o1.Total);            // 99

        // Equality
        Console.WriteLine(new GeoPoint(1, 2) == new GeoPoint(1, 2));            // True (record struct)
        Console.WriteLine(new Order() == new Order());                          // False (identity)

        // Struct inside an array is stored inline: modify through the array element
        var points = new MutablePoint[3];
        points[0].X = 5;                        // modifies the element in place
        var list = new List<MutablePoint> { new() };
        // list[0].X = 5;                       // CS1612: list[0] returns a copy
        var copy = list[0]; copy.X = 5; list[0] = copy;

        // Passing to a method copies the struct, not the class
        Bump(a); BumpOrder(o1);
        Console.WriteLine($"{a.X} {o1.Total}"); // 1 100
    }

    private static void Bump(MutablePoint p) => p.X++;
    private static void BumpOrder(Order o) => o.Total++;
}