Memory Layout and Allocation

Where Data Lives

In .NET, the Garbage Collector (GC) is your silent partner, managing memory so you don't have to. It tracks object lifetimes and cleans up what's no longer needed on the managed heap. Rust takes a different approach. It gives you control over memory layout but enforces rules at compile time to prevent common errors like dangling pointers or data races, all without a GC.

Like C# or C++, a Rust program organizes memory into two primary regions: the stack and the heap. The stack is a highly organized, last-in, first-out (LIFO) structure. When a function is called, a new is pushed onto the stack to hold its local variables. When the function returns, that frame is popped off. This process is incredibly fast because it's just a matter of moving a single pointer.

The stack is for data with a known, fixed size. Think of integers (i32), booleans (bool), and other primitive types. The compiler knows exactly how much space they need before the program even runs.

The heap is less organized. It's a large pool of memory available for the program to use when it needs space for data whose size is unknown at compile time or that might change. Requesting memory from the heap is called 'allocation' and is slower than pushing to the stack. The system has to find a free block of memory of the right size and return a pointer to it.

Data Layout Deep Dive

Unlike .NET, where the runtime and manage object layouts, Rust determines the exact memory layout of every type at compile time. This is a core reason for its performance. It doesn't need to look up object metadata at runtime.

Let's look at a Vec<T>, Rust's growable array, which is similar to a List<T> in C#. A Vec itself isn't one big object. It's a small structure that lives on the stack and holds three key pieces of information:

Part	Type	Description
Pointer	`*mut T`	A memory address pointing to the data on the heap.
Length	`usize`	The number of elements currently in the vector.
Capacity	`usize`	The total number of elements the heap data can hold.

The actual elements of the vector ([1, 2, 3], for example) are stored in a contiguous block of memory on the heap. The Vec on the stack simply knows where to find that data, how much of it is being used, and how much room it has to grow before it needs to ask the heap for a new, larger block of memory.

A String works the same way. It's a Vec<u8> under the hood, with a pointer, length, and capacity on the stack, and the actual UTF-8 text data on the heap. This separation is crucial: it keeps the stack neat and tidy with fixed-size data, while allowing for flexible, dynamic data on the heap.

Putting Things in a Box

So, if types like Vec and String handle their own heap allocation, when do you need to do it yourself? You do it when you have data that has a known type but an unknown size at compile time, or when you have a very large object and you want to avoid copying it.

Rust's primary tool for this is the Box<T> smart pointer. A Box owns data allocated on the heap. When the Box goes out of scope, it automatically deallocates the heap memory, a concept known as RAII (Resource Acquisition Is Initialization). This is Rust's secret to managing memory without a garbage collector.

Here’s how you would put a simple struct on the heap:

struct LargeStruct {
    data: [u8; 1_000_000], // A large array
}

fn main() {
    // `large_data` is a Box smart pointer on the stack.
    // The actual LargeStruct instance is on the heap.
    let large_data = Box::new(LargeStruct { data: [0; 1_000_000] });

    // We can still access the data using the dot operator.
    // The `*` dereference is implicit here.
    println!("First element is: {}", large_data.data[0]);

} // `large_data` goes out of scope here, and the heap memory is freed.

The variable large_data on the stack is just a pointer. The massive LargeStruct lives on the heap. When main finishes, large_data is dropped, and the million-byte allocation is cleaned up instantly.

Sized vs. Unsized

This leads to a final, important concept: the Sized trait. In Rust, everything on the stack must have a known, constant size at compile time. Types that meet this requirement automatically implement the Sized trait.

What about types whose size isn't known? A classic example is a trait object (dyn MyTrait), which could be one of many different structs that implement MyTrait, each with a different size. Another is a slice ([T]), which is a view into an array and can have any length. These types are unsized, or more formally, ?Sized (pronounced "not necessarily Sized").

You cannot store an unsized value in a variable on the stack directly. Rust's compiler will stop you because it can't know how much space to reserve. This is where Box becomes essential.

By putting an unsized value behind a pointer, like Box<dyn MyTrait>, you transform the problem. The value on the stack is now the Box itself, which is just a pointer and has a known, fixed size. The actual, dynamically-sized data lives on the heap.

Understanding this distinction between the stack, the heap, ownership, and the Sized trait is the key to mastering Rust's powerful and safe approach to memory management. It's a mental model that differs from the GC world of .NET but offers fine-grained control and predictable performance in return.

Quiz Questions 1/6

What is the primary difference in memory management strategy between .NET and Rust?

Quiz Questions 2/6

When you create a Vec<i32> in Rust, where are its core components located in memory?

With these fundamentals, you're ready to explore how Rust's ownership and borrowing system builds on this memory model to guarantee safety.

Mastering Rust Memory Safety and Systems Design