Chapter 5: Memory Management in Rust

In Section 1, Getting Started with Systems Programming in Rust, we covered Cargo (the Rust development toolkit), a tour of the Rust language, an introduction to the Rust Standard Library, and standard library modules for managing process environment, command-line, and time-related functions. While the focus of Section 1, Getting Started with Systems Programming in Rust, was to provide an overview of the landscape and the foundation for system programming in Rust, Section 2, Manage and Control System Resources in Rust, gets into the details of how to manage and control system resources in Rust, including memory, files, terminals, processes, and threads.

We are now entering Section 2, Manage and Control System Resources in Rust, of the book. Figure 5.1 provides the context for this section:

Figure 5.1 – Managing system resources

In this chapter, we will focus on memory management. The following are the key...

Technical requirements

Rustup and Cargo must be installed in a local development environment.

The complete code for this chapter can be found at https://github.com/PacktPublishing/Practical-System-Programming-for-Rust-Developers/tree/master/Chapter05.

The basics of OS memory management

In this section, we will go into the fundamentals of memory management in modern OSes. Those already familiar with this topic can skim through this section quickly as a refresher.

Memory is among the most fundamental and critical resources available to a running program (process). Memory management deals with the allocation, use, manipulation, ownership transfer, and eventual release of memory used by a process. Without memory management, executing a program is not possible. Memory management is performed by a combination of components, such as the kernel, program instructions, memory allocators, and garbage collectors, but the exact mechanism varies across programming languages and OSes.

In this section, we will look at the memory management lifecycle and then learn the details of how memory is laid out for a process by the operating system.

The memory management lifecycle

In this section, we will cover the different activities associated...

Understanding the memory layout of Rust programs

In the previous section, we discussed the fundamentals of memory management in modern OSes. In this section, we will discuss how a running Rust program is laid out in memory by the operating system, and the characteristics of the different parts of the virtual memory are used by Rust programs.

Rust program memory layout

In order to understand how Rust achieves the combination of low-memory footprint, memory safety, and performance, it is necessary to understand how Rust programs are laid out in memory and how they can be controlled programmatically.

A low-memory footprint depends on the efficient management of memory allocations, the copying of values, and deallocations. Memory safety deals with ensuring that there is no unsafe access to values stored in memory. Performance depends on understanding the implications of storing a value in the stack versus the heap versus the static data segment. Where Rust shines is that all these...

The Rust memory management lifecycle

Computer programs can be modeled as finite state machines. A running program accepts different forms of inputs (for example, file inputs, command-line arguments, network calls, interrupts, and so on) and transitions from one state to another. Take the case of a device driver. It can be in either of the following states: uninitialized, active, or inactive. When a device driver is just booted up (loaded into memory), it is in the uninitialized state. When the device registers are initialized and ready to accept events, it goes into the active state. It can be put in suspended mode and not ready to accept inputs, in which case it goes into the inactive state. You can extend this concept further. For a communications device like a serial port, the device driver can be in the sending or receiving state. Interrupts can trigger the transitions from one state to another. Likewise, every kind of program, whether it is a kernel component, command-line tool...

Implementing a dynamic data structure

In this section, we will enhance the template engine from Chapter 3, Introduction to the Rust Standard Library and Key Crates for Systems Programming, to add support for multiple template variables in one statement. We will achieve this by converting a static data structure into a dynamic data structure.

We will refresh our memory with the model of the template engine shown in Figure 5.7:

Figure 5.7 – Conceptual model of the template engine (from Chapter 3, Introduction to the Rust Standard Library and Key Crates for Systems Programming)

You will recall that we implemented a template engine in Chapter 3, Introduction to the Rust Standard Library and Key Crates for Systems Programming, to parse an input statement with a template variable and convert it into a dynamic HTML statement using context data provided. We will enhance the template variable feature in this section. We will first discuss the design changes...

Summary

In this chapter, we looked in depth at the memory layout of a standard process in the Linux environment, and then the memory layout of a Rust program. We compared the memory management lifecycle in different programming languages and how Rust takes a different approach to memory management. We learned how memory is allocated, manipulated, and released in a Rust program, and looked at the rules governing memory management in Rust, including ownership and reference rules. We looked at the different types of memory safety issues and how Rust prevents them from using its ownership model, lifetimes, reference rules, and borrow checker.

We then returned to our template engine implementation example from Chapter03 and added a couple of features to the template engine. We achieved this by converting a static data structure into a dynamic data structure and learned how memory is allocated dynamically. Dynamic data structures are very useful in programs that deal with external inputs...

Further reading

Understanding Ownership in Rust: https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html