Stack and Heap Memory Regions

Systems programming relies on two primary memory regions: the stack and the heap. The stack operates as a strict last-in, first-out structure, storing data with a known, fixed size at compile time. It holds primitive values and memory addresses that point to larger, dynamically allocated structures. Because of its predictable layout, stack allocation and deallocation are extremely fast.

The heap accommodates data whose size is unknown at compile time or may change during execution. When you request heap memory, the allocator finds a sufficiently large block, marks it as in use, and returns a pointer. This pointer is then stored on the stack. Heap allocation involves more overhead due to bookkeeping and potential fragmentation, but it is essential for growable collections and complex objects.

The Ownership Paradigm

Traditional languages manage memory either manually (C/C++) or via a garbage collector (Java, Go, Python). Manual management risks memory leaks and use-after-free vulnerabilities, while garbage collection introduces runtime overhead and unpredictable pause times. Rust eliminates both trade-offs through a compile-time ownership system that guarantees memory safety without a runtime collector.

The model enforces three foundational principles:

• Every piece of data has exactly one owning variable.
• Ownership is exclusive; only one owner can exist at any given time.
• When the owner exits its lexical scope, the data is automatically deallocated.

Lexical Scope and Resource Lifetimes

A variable's validity is strictly bound to the block in which it is declared. The compiler uses these boundaries to determine precisely when resources should be reclaimed.

{
    // `record` does not exist yet
    let record = "scope_bound_data";
    // `record` is valid and accessible here
}
// `record` has gone out of scope and is no longer usable

Heap Allocation and Automatic Cleanup

Fixed-size types fit neatly on the stack, but dynamic structures require heap storage. In manual memory management languages, developers must explicit invoke deallocation routines. Rust automates this process deterministically. When a variable owning heap data goes out of scope, the compiler implicitly injects a call to the drop function, ensuring immediate cleanup without runtime tracing or reference counting.

Move Semantics vs. Explicit Cloning

Assignment behavior in Rust depends entirely on where the underlying data resides. Stack-only types implement the Copy trait, meaning assignment duplicates the bitwise value:

let alpha = 42;
let beta = alpha; // `alpha` is copied to `beta`
// Both variables remain fully usable

Types such as i32, bool, f64, char, and tuples containing only copyable types follow this pattern.

Heap-backed types behave differently. Assigning them transfers ownership rather than duplicating the underlying buffer:

let primary = String::from("dynamic_payload");
let secondary = primary; // Ownership moves to `secondary`
// `primary` is now invalidated

Internally, only the stack metadata (pointer, capacity, and length) is copied. The heap buffer remains untouched. If both variables remained active, exiting the scope would trigger a double-free error. Rust prevents this by invalidating the source variable immediately after the move operation.

When an actual duplicate is required, explicit cloning must be used:

fn main() {
    let source = String::from("replicate_content");
    let duplicate = source.clone(); // Deep copy of heap data
    println!("Original: {}, Copy: {}", source, duplicate);
}

Cloning allocates new heap memory and copies the contents, allowing both variables to own independant resources. This carries a performance cost and should be invoked intentionally.

Ownership Across Function Boundaries

Passing arguments to functions follows identical move/copy semantics. Transferring a heap-allocated value into a function relinquishes ownership from the caller:

fn main() {
    let payload = String::from("transfer_data");
    consume_value(payload); // Ownership moves into the function
    // `payload` can no longer be accessed here

    let counter = 10;
    process_number(counter); // `i32` implements Copy
    // `counter` remains valid
}

fn consume_value(data: String) {
    println!("Received: {}", data);
} // `data` is dropped here

fn process_number(num: i32) {
    println!("Number: {}", num);
} // `num` is copied, no drop required

Returning values similarly transfers ownership back to the caller:

fn main() {
    let acquired = generate_text(); // Ownership moves to `acquired`
    let local = String::from("pass_through");
    let result = process_and_return(local); // `local` moves in, result moves out
} // `result` and `acquired` are dropped here

fn generate_text() -> String {
    let internal = String::from("created_inside");
    internal // Moved out to the caller
}

fn process_and_return(input: String) -> String {
    input // Ownership transferred back
}

Borrowing and References

Constantly moving ownership is impractical for read-only operations or shared access. Rust introduces borrowing, allowing functions to inspect data without taking ownership. References are created with the & operator:

fn main() {
    let content = String::from("inspect_only");
    let view = &content; // Immutable borrow
    println!("Content: {}, View: {}", content, view);
}

Borrowing grants temporary access. The original owner retains responsibility for cleanup. Function parameters can accept references to avoid ownership transfer:

fn main() {
    let text = String::from("measure_this");
    let size = get_length(&text);
    println!("'{}' has {} characters.", text, size);
}

fn get_length(s: &String) -> usize {
    s.len()
}

References are essentially pointers with strict compile-time guarantees. They do not own the data they point to, and borrowing rules enforce memory safety:

• You may have multiple immutable references (&T) simultaneously.
• You may have exactly one mutable reference (&mut T) at a time.
• Mutable and immutable references cannot coexist for the same data.

Attempting to mutate through an immutable reference fails compilation:

fn main() {
    let base = String::from("static_value");
    let viewer = &base;
    // viewer.push_str("_modified"); // Compile error: cannot mutate immutable borrow
}

To modify borrowed data, a mutable reference is required:

fn main() {
    let mut buffer = String::from("base");
    let editor = &mut buffer;
    editor.push_str("_extended");
    println!("Result: {}", editor);
}

The restriction on simultaneous mutable references prevents data races at compile time. If multiple execution paths could read and write simultaneously, memory corruption would occur. Rust's borrow checker eliminates this entire class of concurrency bugs.

Dangling References

A dengling reference occurs when a pointer outlives the data it points to. Rust's compiler strictly forbids this scenario:

fn main() {
    let invalid_ref = create_dangling(); // Compile error
}

fn create_dangling() -> &String {
    let temp = String::from("short_lived");
    &temp // Error: `temp` is dropped at function end, reference would dangle
}

Since temp is deallocated when the function returns, returning a reference to it would point to reclaimed memory. The borrow checker detects the lifetime mismatch and rejects the code before it can execute.