speice.io/_drafts/understanding-allocations-in-rust.md

layout	title	description	category	tags
post	Understanding Heap Allocations in Rust	An introduction to the Rust memory model		rust

There's an alchemy of distilling complex technical topics into articles and videos that change the way programmers see the tools they interact with on a regular basis. I knew what a linker was, but there's a staggering amount of complexity in between main() and your executable. Rust programmers use the Box type all the time, but there's a rich history of the Rust language itself wrapped up in how special it is.

In a similar vein, I want you to look at code and understand how memory is used; the complex choreography of operating system, compiler, and program that frees you to focus on functionality far-flung from frivolous book-keeping. The Rust compiler relieves a great deal of the cognitive burden associated with memory management, but we're going to step into its world for a while.

Let's learn a bit about memory in Rust.

Table of Contents

This post is intended as both guide and reference material; we'll work to establish an understanding of the different memory types Rust makes use of, then summarize each section for easy citation in the future. To that end, a table of contents is provided to assist in easy navigation:

• Foreword
• Stacking Up: Non-Heap Memory Types
• Piling On: Rust and the Heap
• Compiler Optimizations Make Everything Complicated
• Summary: When Does Rust Allocate?
• Appendix and Further Reading

Foreword

There's a simple checklist to see if you can skip over reading this article. You must:

1. Only write #![no_std] crates
2. Never use unsafe
3. Never use #![feature(alloc)]

For some uses of Rust, typically embedded devices, these constraints make sense. They're working with very limited memory, and the program binary size itself may significantly affect what's available! There's no operating system able to manage this "virtual memory" junk, but that's not an issue because there's only one running application. The embedonomicon is ever in mind, and interacting with the "real world" through extra peripherals is accomplished by reading and writing to exact memory addresses.

Most Rust programs find these requirements overly burdensome though. C++ developers would struggle without access to std::vector (except those hardcore no-STL guys), and Rust developers would struggle without std::vec. But in this scenario, std::vec is actually part of the alloc crate, and thus off-limits (because the alloc crate requires #![feature(alloc)]). Or how would you use trait objects? There's no Box<dyn Trait> available to use for dynamic dispatch.

Whether writing code for embedded devices or not, the important thing in both situations is how much you know before your application starts about what your memory usage looks like. In the embedded device example, there's a small, fixed amount of memory you can possibly use. In a browser, however, you have no idea how large [google.com's home page] is until you start trying to download it. The compiler uses this information (or lack thereof) to optimize how memory is used; put simply, your code runs faster when the compiler can guarantee exactly how much memory your program needs while it's running. This post is all about understanding the optimization tricks the compiler uses, and how you can help the compiler and make your programs more efficient.

Now let's address some conditions and caveats before going much further. This article will focus on "safe" Rust only; unsafe mode allows you to make use of platform-specific allocation API's (think the [libc] and [winapi] implementations of [malloc]) that we'll ignore. We'll also assume a "debug" build of libraries and applications (what you get with cargo run and cargo test) and address (hehe) "release" mode at the end (cargo run --release and cargo test --release).

Finally, while the details are unlikely to change, the Rust docs include a warning worth repeating here:

Rust does not currently have a rigorously and formally defined memory model.

• the Rust docs

Stacking Up: Non-Heap Memory Types

Languages like Java and Python do an amazing job of simplifying the memory model needed for programmers. You can essentially treat

Most of the reason this post was written is because I Everyone's agreed that compilers are smart, and Rust is no exception.

Example: Why doesn't Vec::new() go to the allocator?

Questions:

1. What is the "Push" instruction? Why do we like the stack?
2. How does Rust allocate arguments to the function?
3. How does Rust allocate variables created in the function but never returned?
4. How does Rust allocate variables created in the function and returned?
5. How do Option<> or Result<> affect structs?
6. How are arrays allocated?
7. Legal to pass an array as an argument?

Piling On - Rust and the Heap

Example: How to trigger a heap allocation

Questions:

1. Where do collection types allocate memory?
2. Does a Box<> always allocate heap?
   • Yes, with exception of compiler optimizations
3. Passing Box vs. genericizing/monomorphization
   • If it uses dyn Trait, it's on the heap.
4. Other pointer types? Do Rc<>/Arc<> force heap allocation?
   • Maybe? Part of the alloc crate, but should use qadapt to check

Compiler Optimizations Make Everything Complicated

Example: Compiler stripping out allocations of Box<>, Vec::push()

Appendix and Further Reading

Embedonomicon:

[libc]: CRATES.IO LINK [winapi]: CRATES.IO LINK [malloc]: MANPAGE LINK