Goals … Summary · OSTEP Interactive

The OS won’t merely virtualize memory — it will do so with style. Three goals keep it honest, and they’ll grade every mechanism from base/bounds to multi-level page tables.

13.4 Goals

Transparency

The illusion must be invisible: the program behaves as if it owns private physical memory, while OS + hardware multiplex behind the scenes. (Transparent here means hard to notice — the opposite of the open-government kind, as the book’s footnote clarifies for confused students.)

Efficiency

In time (programs shouldn’t run much slower) and space (translation structures shouldn’t eat the memory they manage). Time-efficiency will demand hardware help — including a gadget called the TLB, due in chapter 19.

Protection

No load, store, or instruction fetch may touch anything outside the process’s own address space — not other processes, not the OS. Protection delivers isolation : each process in its own cocoon, safe from faulty or malicious neighbors.

Tip: The principle of isolation

If two entities are properly isolated, one can fail without harming the other. The OS isolates processes from each other; memory isolation keeps them from harming the OS itself. Some systems push further and wall off pieces of the OS from other pieces of the OS — the microkernel design — trading structure for reliability beyond what monolithic kernels offer.

The plan from here: mechanisms first, bottom-up — hardware and OS support for translation — then the policies (managing free space, deciding what to evict when memory runs low). Make it through virtual memory , the book promises, and you’ll likely make it all the way. (The alternative — being convinced to drop the course — is listed as an explicit possibility.)

13.5 Summary — and the aside worth the price of the chapter

The VM system provides a large, sparse, private address space to each program; the OS (with serious hardware help) turns every virtual reference into a physical one, for many processes at once, protecting all. Mechanisms first, starting next chapter — but first, proof you’ve been living inside the illusion all along:

Aside: Every address you see is virtual

Ever printed a pointer in C? That number was a virtual address. The location of your program’s code? Also virtual. Any address you can see as a user-level programmer is a virtual address. Only the OS, through its tricky techniques, knows where in physical memory these bytes really lie. It’s an illusion of layout — chant chapter 12’s mantra once more, and then print the evidence yourself:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
  printf("location of code : %p\n", main);
  printf("location of heap : %p\n", malloc(100e6));
  int x = 3;
  printf("location of stack: %p\n", &x);
  return x;
}

Run on a 64-bit Mac (va.c):

location of code : 0x1095afe50
location of heap : 0x1096008c0
location of stack: 0x7fff691aea64

Exactly the Figure 13.3 layout, at real-life scale — code first, heap just after, stack a staggering distance away at the far end:

va.c on a 64-bit Mac: three printed addresses, one vast and mostly-empty virtual space

click a region marked ⓘ for details

Homework (code): free, memory-user.c, pmap

Meet the Linux tools that show virtualization in action: read man free and check your system’s totals; write memory-user.c (allocate N megabytes and stream through the array forever) and watch free move while it runs; then aim pmap -X at your program (print your PID with getpid()) and count how many entities a REAL address space contains beyond our tidy code/stack/heap trio. Details at ostep-homework.

Check yourself

1.What does 'transparency' mean as a virtual-memory goal?

2.Efficiency as a VM goal has two dimensions. Which pairing is right?

3.How do microkernels extend the principle of isolation?

4.va.c prints code at 0x1095afe50, heap at 0x1096008c0, and stack at 0x7fff691aea64. What's the takeaway?

4 questions