Rust Memory Model & Internals on Atharva Pandey

Lesson 10: How rustc Works — From source code to binary

Sat, 22 Mar 2025 11:30:00 +0000

A junior on my team once asked why Rust compiles so slowly compared to Go. I gave the standard answer about monomorphization and LLVM, but realized I couldn’t actually explain the full pipeline. So I spent a weekend reading the rustc dev guide and poking at compiler internals. What I found was a surprisingly elegant six-stage pipeline, and understanding it changed how I think about Rust’s design tradeoffs.

The Big Picture

When you run cargo build, your source code goes through six major stages before becoming a binary:

Lesson 9: Miri — Your safety net for unsafe Rust

Wed, 19 Mar 2025 08:45:00 +0000

I once shipped a Rust library with an unsafe block that worked perfectly on x86, passed all tests, and ran flawlessly in production for months. Then someone compiled it on ARM and it segfaulted immediately. The undefined behavior had been lurking the whole time — x86 just happened to tolerate the misaligned read that ARM wouldn’t. If I’d run Miri before releasing, I would have caught it in thirty seconds. Lesson learned the hard way.

Lesson 8: Custom Allocators — GlobalAlloc, arena allocation, and beyond

Sun, 16 Mar 2025 13:10:00 +0000

I was building a JSON parser that processed millions of small documents per second. Profiling showed that 40% of the time was spent in malloc and free — not parsing, not I/O, just allocating and deallocating tiny strings and vectors. Switched to an arena allocator that bulk-freed everything after each document, and throughput doubled. That experience taught me that the allocator isn’t just plumbing — it’s a performance lever.

How Rust Allocates Memory

When you write Box::new(42) or Vec::with_capacity(100), Rust asks the global allocator for memory. By default, this is the system allocator — malloc/free on Unix, HeapAlloc/HeapFree on Windows. It’s a general-purpose allocator designed to handle any allocation pattern reasonably well, but it’s not optimized for any specific pattern.

Lesson 7: Drop Order — Deterministic destruction and why it matters

Thu, 13 Mar 2025 07:20:00 +0000

I once had a deadlock in a Rust program that only manifested during shutdown. A mutex guard and a database connection were being dropped in the wrong order — the connection’s destructor tried to acquire the mutex that was already locked by the guard that hadn’t been dropped yet. Rust’s drop order is deterministic, but “deterministic” doesn’t mean “obvious.” Knowing the rules saved me hours of debugging.

The Drop Trait

In Rust, cleanup logic is implemented through the Drop trait. When a value goes out of scope, the compiler calls drop() on it automatically. This is RAII — Resource Acquisition Is Initialization — borrowed from C++ but made more reliable by the ownership system.

Lesson 6: repr(C), repr(transparent), repr(packed) — Taking control of memory layout

Tue, 11 Mar 2025 09:55:00 +0000

The first time I wrote Rust FFI bindings to a C library, I defined a struct, passed it across the boundary, and got garbage data back. The C side was reading fields at fixed offsets, but Rust had silently reordered my fields for padding efficiency. Took me twenty minutes of staring at hex dumps to realize the layouts didn’t match. That’s the day I learned about #[repr(C)].

Default Rust Layout: repr(Rust)

By default, Rust structs use repr(Rust) — the compiler is free to reorder fields, add padding wherever it wants, and generally optimize the layout however it sees fit. The only guarantees are:

Lesson 5: Fat Pointers — &dyn Trait, &[T], and &str under the hood

Sun, 09 Mar 2025 16:40:00 +0000

I remember being confused why &str was 16 bytes on a 64-bit system. A pointer is 8 bytes — what’s the other 8? That question sent me down a rabbit hole that fundamentally changed how I think about Rust’s type system. Turns out, some references carry extra baggage, and that baggage is the entire reason dynamically sized types work.

Thin Pointers vs Fat Pointers

Most references in Rust are “thin” — a single machine word pointing to the data:

Lesson 4: vtables — How dyn Trait actually works under the hood

Fri, 07 Mar 2025 11:15:00 +0000

I was profiling a parser once and found that a hot path using dyn Iterator was 3x slower than the equivalent code using generics. The algorithm was identical. The difference? Dynamic dispatch — every method call went through a vtable lookup instead of being inlined. That day I learned to respect what dyn really costs. Let’s open the hood.

Static vs Dynamic Dispatch

Rust gives you two ways to call methods on trait objects: static dispatch (generics) and dynamic dispatch (dyn Trait).

Lesson 3: Box — Heap allocation by choice

Wed, 05 Mar 2025 08:30:00 +0000

When I first started writing Rust, I used Box everywhere. Came from a Java background where everything lives on the heap, and wrapping things in Box felt natural. Took me a while to realize I was fighting the language — most of the time, you don’t need it. But when you do need Box, nothing else will do.

What Box Actually Is

Box<T> is the simplest smart pointer in Rust. It allocates a value of type T on the heap and gives you ownership of that allocation through a pointer on the stack. When the Box goes out of scope, it frees the heap memory. That’s it. No reference counting, no garbage collection, no magic.

Lesson 2: Stack vs Heap — Where your data actually lives

Mon, 03 Mar 2025 14:45:00 +0000

A colleague once asked me why their Rust program was ten times slower than expected. They were allocating a Vec<u8> inside a tight loop — millions of heap allocations per second. Moved the vec outside the loop, pre-allocated with with_capacity, and the function went from 2 seconds to 80 milliseconds. Stack vs heap isn’t an academic distinction. It’s the difference between fast code and slow code.

Two Memory Regions, Two Personalities

Your program has (at minimum) two regions of memory to work with: the stack and the heap. They behave differently, perform differently, and serve different purposes. Rust makes the choice between them more explicit than most languages, which is one of the reasons it’s fast by default.

Lesson 1: Memory Layout — Size, alignment, and the padding you never asked for

Sat, 01 Mar 2025 10:22:00 +0000

I spent an embarrassing amount of time debugging a networking project where my hand-crafted packet structs were mysteriously three bytes too large. Turns out the compiler was inserting padding I didn’t know about. That’s when I realized most Rust developers — myself included — treat memory layout as a black box. Let’s crack it open.

Why Layout Matters

Every type in Rust has two fundamental properties: size and alignment. The size is how many bytes the value occupies. The alignment is which memory addresses the value is allowed to start at. These two numbers determine everything about how your data sits in memory, how much RAM your program uses, and whether your structs can talk to C code or hardware registers.