How does virtual memory work? October 29, 2018 on Drew DeVault's blog

Virtual memory is an essential part of your computer, and has been for several decades. In my earlier article on pointers, I compared memory to a giant array of octets (bytes), and explained some of the abstractions we make on top of that. In actual fact, memory is more complicated than a flat array of bytes, and in this article I’ll explain how.

An astute reader of my earlier article may have considered that pointers on, say, an x86_64 system, are 64 bits long¹. With this, we can address up to 18,446,744,073,709,551,616 bytes (16 exbibytes²) of memory. I only have 16 GiB of RAM on this computer, so what gives? What’s the rest of the address space for? The answer: all kinds of things! Only a small subset of your address space is mapped to physical RAM. A system on your computer called the MMU, or Memory Management Unit, is responsible for managing the abstraction that enables this and other uses of your address space. This abstraction is called virtual memory.

The kernel interacts directly with the MMU, and provides syscalls like [mmap(2)][mmap] for userspace programs to do the same. Virtual memory is typically allocated a page at a time, and given a purpose on allocation, along with various flags (documented on the mmap page). When you call malloc, libc uses the mmap syscall to allocate pages of heap, then assigns a subset of that to the memory you asked for. However, since many programs can run concurrently on your system and may request pages of RAM at any time, your physical RAM can get fragmented. Each time the kernel hits a context switch³, it swaps out the page table for the next process.

This is used in this way to give each process its own clean address space and to provide memory isolation between processes, preventing them from accessing each other’s memory. Sometimes, however, in the case of shared memory, the same physical memory is deliberately shared with multiple processes. Many pages can also be any combination readable, writable, or executable - the latter meaning that you could jump to it and execute it as native code. Your compiled program is a file, after all - mmap some executable pages, load it into memory, jump to it, and huzzah: you’re running your program⁴. This is how JITs, dynamic recompiling emulators, etc, do their job. A common way to reduce risk here, popular on *BSD, is enforcing W^X (writable XOR executable), so that a page can be either writable or executable, but never both.

Sometimes all of the memory you think you have isn’t actually there, too. If you blow your RAM budget across your whole system, swap gets involved. This is when pages of RAM are “swapped” to disk - as soon as your program tries to access it again, a page fault occurs, transferring control to the kernel. The kernel restores from swap, damning some other poor process to the fate, and returns control to your program.

Another very common use for virtual memory is for memory mapped I/O. This can be, for example, mapping a file to memory so you can efficiently read and write to disk. You can map other sorts of hardware, too, such as video memory. On 8086 (which is what your computer probably pretends to be when it initially boots⁵), a simple 96x64 cell text buffer is available at address 0xB8000. On my TI-Nspire CX calculator, I can read the current time from the real-time clock at 0x90090000.

In summary, MMUs arrived almost immediately on the computing scene, and have become increasingly sophisticated ever since. Virtual memory is a powerful tool which grants userspace programmers elegant, convenient, and efficient access to the underlying hardware.