§15.1–15.2Assumptions … An Example

CPU virtualization ran on limited direct execution: let the program run directly on the hardware, but interpose at key moments to keep control. Memory virtualization pursues the same bargain — efficiency (with hardware help, starting from just a few registers), control (no process touches memory that isn’t its own), plus one new demand: flexibility — programs should use their address spaces however they like.

The generic technique — the addition to LDE — is hardware-based address translation address translation Hardware transforming every memory reference's virtual address into a physical one — LDE's memory-side twin. defined in ch. 15 — open in glossary : on each and every memory reference (instruction fetch, load, or store), the hardware transforms the virtual address into the physical address where the data actually lives. Hardware provides the fast mechanism; the OS manages memory (tracking free and used) and steps in at the key moments. The goal, as ever: the beautiful illusion of private memory, hiding the ugly truth of many programs sharing it.

15.1 Assumptions

First attempts will be simple — “laughably so. Go ahead, laugh all you want; pretty soon it will be the OS laughing at you, when you try to understand the ins and outs of TLBs and multi-level page tables. That’s just how the OS rolls.”

15.2 An Example

Take the humblest line of C and watch what memory work it causes:

void func() {
    int x = 3000; // thanks, Perry.
    x = x + 3;    // line of code we are interested in
    ...

The compiler emits three x86 instructions (disassemble with objdump on Linux, otool on a Mac). The address of x waits in %ebx:

128: movl 0x0(%ebx), %eax    ;load 0+ebx into eax
132: addl $0x03, %eax        ;add 3 to eax register
135: movl %eax, 0x0(%ebx)    ;store eax back to mem

Here’s where everything lives in the process’s 16KB view:

Running those three instructions produces six memory accesses, from the process’s perspective:

(Instruction fetches count! Chapter 2 warned that memory is touched on every fetch — here it’s 3 of the 5 accesses.)

Now the problem. The program believes its space runs 0–16KB, and every reference it generates will be in that range. But the OS wants to place it somewhere else — say at physical 32KB:

How can the process be relocated transparently — the illusion of an address space at 0, while the truth is 32KB? Every one of those six accesses must be quietly redirected, at full speed. The 1950s answer — two little registers — is next.