Other Tricks

Memory-Mapped Files

So far, we've mostly talked about demand-paging the code for a program and paging out unused data to swap space, but we can generalize this idea to include files as well, using memory-mapped files.

Here's an example program, main.c, that maps its own source code into memory and then counts the number of lines in the file:

#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int
main() {
        int fd = open("main.c", O_RDONLY);
        struct stat sb;
        fstat(fd, &sb);
        char *addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
        close(fd);
        printf("Mapped %zd bytes of main.c into memory at %p\n", sb.st_size, addr);

        int lines = 0;
        for (int i = 0; i < sb.st_size; i++) {
                if (addr[i] == '\n') {
                        lines++;
                }
        }

        printf("There are %d lines in main.c\n", lines);
        munmap(addr, sb.st_size);
        return 0;
}

• Try this code in OnlineGDB

Shared Memory

We've already mentioned that if code is read only, it can be shared by all the processes running that code. But the virtual-memory system can also be used to share read-write data between processes with shared memory. Mapping the same writable file into two processes is one way to share memory between them.

Shared Libraries

Besides the executable code, most programs also need to use various libraries, such as the C library that provides functions like strlen and printf, the C++ library that provides classes like std::string and std::iostream, and other useful libraries like libpng for reading and writing PNG files.

In the past, when you linked your program, the linker would work out which parts of the library you needed and copy them into your program (which is one reason why they were called libraries, because you just got the parts you needed). But this approach is wasteful if you're running many programs that all use the same functions from the same library.

Today we tend to map the entire library into memory and share it between all the programs that need it. These are known as shared libraries. We rely on demand paging to only load the parts of the library that are actually in use.

Shared Libraries on Linux and Windows

On Linux and Windows, although the physical frames are shared between processes, each process has its own copy of the page-table entries that map the shared library into memory, which allows each process to choose where in its address space it maps each library it wants. It can even map the library to different addresses in different runs of the same program. This approach does mean that each library needs a complete set of page-table entries for each process that uses it. Windows adds an optimization: when possible, it tries to load shared libraries at the same address in different processes, allowing the page-table entries to be shared.

Shared Libraries on macOS

On macOS, the system uses a single large shared region (also known as a submap) for all libraries that are part of the operating system. This region is mapped into every process's address space, and the page-table entries for the shared region are shared between all processes. The system only needs to keep one set of page-table entries for each library, no matter how many processes are using it. But it also means that each process has to map the library at the same address in its address space, and may have libraries in its address space that it never uses.

Speculative Page Loading

When a program is reading a memory-mapped file sequentially, it's a good bet that the program plans to read in the entire file, or at least a large chunk of it. With most kinds of disks, it's almost the same cost to make a big read as a small one, so the OS can read in more than it needs and hope that the program will ask for the speculatively read data soon.

In macOS, these speculatively read pages go on their own page queue in the VM system, because keeping these pages around isn't essential. If they're not used soon after they were loaded, they probably won't be used at all.

Copy-on-Write (Helping Forks)

When a process forks, the child process gets a copy of the parent's address space. But if the child never writes to that memory, it's a waste of time and memory to actually duplicate the memory. Instead, the OS can use copy-on-write.

In copy-on-write, the OS marks the pages as read-only in both the parent and child processes. If either process tries to write to the memory, the OS makes a copy of the affected page and gives it to the writing process; pages that no one writes to don't have to be duplicated.

Purgable Memory

When Apple launched the iPhone, they wanted to use the same core operating system as macOS, but they had to make some changes to make it work well on a phone. One issue with a phone is that the secondary storage is flash memory that can only be written to a limited number of times. So the operating system needs to be careful about how it uses memory, and shouldn't just swap out pages to disk whenever it feels like it—they decided the best approach was to have no swap space on the iPhone.

Purgable memory is memory a program has that it technically doesn't need. An example is hidden tabs in your web browser—the browser can keep an image of what's on the page so that if you switch tabs it can show you the page right away, but if you never switch back to that tab, it's just wasting memory. And if it had to, your browser could redraw the page from scratch (or even reload it entirely from the Internet). So the program can mark that memory as purgable, meaning that it can be thrown away if the system needs the memory for something else.

Killing Processes to Free Memory

If there isn't enough free memory, and we don't reclaim enough by throwing out purgable memory, there is one more option—terminate some of the processes on the machine to free up memory. On iOS, the kernel first asks the program nicely to wind up its affairs and exit, but if it doesn't do so quickly, the kernel will kill the process. Programs for iOS are generally expected to be able to quit and restart fairly transparently, so this possibility isn't as big a deal as it might be on a desktop system.

Linux has a similar feature, called the OOM killer (Out-Of-Memory killer). When the system runs out of memory, the kernel will pick a process to kill based on a variety of factors, such as how much memory the process is using, how much CPU time it's using, and how long it's been since the process was started. The OOM killer will send a signal to the process, giving it a chance to clean up and exit gracefully, but if it doesn't, the kernel will kill the process.

Address-Space Layout Randomization

One of the ways that attackers can exploit a program is by knowing where things are in memory. For example, if the attacker knows where the stack is, they can overwrite the return address of a function and take control of the program. To make these kinds of attacks harder, the operating system can randomize the layout of the address space with address-space–layout randomization (ASLR).

ASLR works by placing all the pieces of the address space (the stack, the heap, the code, the shared libraries) at random locations in memory. Now the attacker doesn't know where the stack is—they have to find it before they can do anything else, which makes it much harder to exploit a program.

Today macOS, Linux, and Windows all use ASLR to protect against attacks. It doesn't prevent attacks, but it makes them harder to pull off.

Wired Memory

Wired memory is just memory that is “wired down”—it can't be paged out. The term is used by the macOS and BSD kernels, and refers to memory that the kernel has decided needs to stay in memory no matter what. For example, critical information about each process, or memory that is actively being used for I/O cannot be paged out.

(When logged in, completion status appears here.)