Memory management and address translation

1. A process has an address space

A program runs by fetching instructions and reading or writing data. Every such operation refers to an address. If those addresses were unrestricted physical locations, a mistake in one program could overwrite another program or the operating system itself. Memory management must provide usable storage while controlling which locations each execution context can reach. It must also allow deliberate sharing, because shared code and communication can be valuable.

The central abstraction is the address space: the collection of addresses a process can use, together with the mappings and access rules that give those addresses meaning. A virtual address is interpreted in a process context. Two processes can use the numerical address 0x1234 and access different physical locations. Conversely, two different virtual addresses can map to the same physical location when sharing is intended. Neither equality nor inequality of the printed numbers settles whether the underlying storage is shared.

The operating system establishes and changes mappings. Hardware uses them during execution and rejects disallowed accesses. Keeping these roles distinct explains why the OS does not need to execute a system call for every ordinary load or store. It is involved in setting up the policy and in exceptional events; the normal access path can proceed through hardware translation and permission checks.

2. Binding names to addresses

Source programs refer to symbolic objects such as a variable or function. Compilation produces object code whose references may still need adjustment. Linking combines modules and resolves references; loading places the resulting program into a usable address space. These transformations explain why a name in source code, an offset in an object module and an address used by a running process are not interchangeable descriptions.

Compile-time binding assumes a known placement and generates addresses accordingly. Load-time binding leaves relocation to the loader. Execution-time binding permits an address generated during execution to be translated to its current physical location. These are conceptual alternatives, not a claim that a contemporary executable performs only one kind of address resolution throughout its life.

Dynamic loading delays bringing a routine into use until it is needed. Dynamic linking delays resolving a connection to separately supplied library code. A program can use either idea without making them synonymous. Shared library code can be mapped by several processes, but writable state and permissions still require careful treatment. Demand paging, introduced next week, adds another distinction: a mapped virtual range need not have all its pages resident in RAM at once.

3. Relocation and bounds must work together

Start with a deliberately small model: a process generates a nonnegative logical offset, and a relocation register contains the physical base of its allocated region. Translation adds the base to the offset. With base 14000, logical offset 346 becomes physical address 14346. If the region moves and the base changes, the process can keep using the same offsets.

Translation alone is insufficient. An offset outside the allocated length would still produce a number, but that number could refer to someone else’s memory. With limit 1000, the legal offsets are 0 through 999 inclusive. The check is offset < limit, not offset ≤ limit. Only after the check succeeds should the mechanism add the base.

Another textbook diagram checks an already physical address against the interval base ≤ address < base + limit. That is a different placement of the check. Read the diagram’s input label before applying a formula. Mixing the physical-interval model with the offset model is a common source of off-by-one and double-addition errors.

4. Contiguous allocation and placement policies

In contiguous allocation, a process is assigned one continuous physical interval. Free intervals are holes. A new allocation can split a hole into an allocated region and a smaller remaining hole. When an allocation is freed, adjacent holes can be coalesced. These operations change the future choices, so a placement policy must be evaluated on a sequence rather than a single request.

First fit searches in address order and selects the first hole large enough. Best fit selects the smallest sufficient hole. Worst fit selects the largest. For a reproducible comparison, begin each policy with the same state and state how ties, splitting and coalescing work. In the following exercise, holes are listed in address order; the chosen hole is split; no process exits during the sequence.

After the first three first-fit allocations, the holes are 100, 176, 200, 300 and 183 KiB. Their sum is 959 KiB, yet the next request of 426 KiB cannot fit because the largest single hole is only 300 KiB. Best fit succeeds for this particular sequence. That observation is an example outcome, not a proof that best fit dominates every possible workload.

5. Two kinds of fragmentation

External fragmentation means that free space exists between allocations but cannot satisfy a requirement for one sufficiently large contiguous region. Internal fragmentation means that an allocated unit contains unused bytes. The external case concerns how free regions are arranged; the internal case concerns unused space inside a reserved unit. Always name the unit and allocation model when using these terms.

Compaction can gather scattered free space by moving allocated regions. It requires safe relocation of references and incurs copying cost. An outstanding I/O operation might still refer to the old location; the system must coordinate that operation or use an appropriate buffering arrangement. “Move the process” is therefore a policy idea with implementation obligations, not a cost-free diagram operation.

Paging changes the allocation unit to fixed-sized frames. A process can use separated frames, which removes the requirement for one large contiguous process region. Its final page can still be partially unused. Other system allocations may still require contiguous physical regions, so it is too broad to conclude that paging eliminates every fragmentation issue in an entire operating system.

6. Segmentation as a logical organization

A programmer may think of memory as several logical regions: code, a stack, tables and arrays. Segmentation represents that view using variable-sized regions. An address is a pair (segment number, offset). The segment number chooses a table entry; that entry supplies the region’s base and length, along with permissions. The offset must be within the segment before the base is added.

For segment 0 with base 1400 and length 1000, offset 430 reaches physical address 1830. Segment 1 with base 6300 and length 400 admits offset 399, producing 6699, but rejects offset 400. The existence of physical byte 6700 is irrelevant to whether that segment permits the reference.

Segmentation makes region boundaries explicit, but allocating variable-sized regions can produce external fragmentation. Paging uses uniform units that do not need to correspond to source-language objects. Some historical architectures combine the mechanisms: segmentation produces a linear address, which paging then translates. Here segmentation supplies context and comparison; it is not a claim that current Ubuntu processes use the historical BIL601 diagram unchanged.

7. Pages, frames and offset preservation

A page is a fixed-sized unit of virtual memory; a frame is a same-sized unit of physical memory. A page table records the mapping from a virtual page number to a frame. The process can see consecutive virtual addresses even when the frames backing consecutive pages are separated in RAM. The offset identifies a byte within the page and is preserved during translation.

For byte address A and page size P, compute p = floor(A/P) and d = A mod P. After finding a valid, permitted mapping to frame f, the physical address is f × P + d. Do not add the original whole virtual address to the frame base: that would count the virtual-page contribution a second time.

If P is 2ⁿ bytes, the low n address bits are the offset. With 4 KiB pages, n = 12. A 32-bit virtual address then has 20 virtual-page bits and 12 offset bits. The physical frame-number width is determined by the physical address space, not automatically by the virtual width. Using KiB and MiB explicitly avoids confusing powers of two with decimal units.

8. Work a translation all the way to a byte

In the original miniature example, virtual pages 0, 1, 2 and 3 map to frames 5, 6, 1 and 2. Virtual address 6 has page number 1 and offset 2, so it reaches physical address 6 × 4 + 2 = 26. Distinguish the virtual address 6 from frame number 6: they are numerically equal here but have different meanings.

Now use a larger teaching table. Page size is 4096 bytes. Every mapped page below is resident; the table deliberately separates mapping existence from permission. We will use the same state in the supplied simulator so predictions can be checked exactly.

A read at 0x1234 starts with decimal address 4660. Dividing by 4096 gives page 1 and remainder 564, or 0x234. Page 1 selects frame 9, whose physical base is 36864, or 0x9000. The result is 37428, or 0x9234. The low twelve bits are unchanged. A write at the same address is rejected, because that mapping is read-only.

9. Page tables and the address of an entry

A page table is metadata, not a second copy of the program. It records which frame, if any, corresponds to a virtual page and which operations are permitted. In a simple one-level model, the page-table base register identifies a physical table base. If entries have fixed size, the page number indexes an entry by ordinary arithmetic.

Assume PTBR = 0x8000 and an entry size of eight bytes. Page 1’s entry is stored at 0x8008. Reading that entry may reveal frame 9, but 0x8008 is not the address of the program’s data. For offset 0x234, the data address is 0x9234. Students should explicitly label the entry address, the entry contents and the final data address; collapsing them into one number hides the mechanism.

Without a translation cache, a one-level translation requires reading the PTE and then accessing the requested instruction or data. This explains why a straightforward table in RAM can add substantial overhead. The normal solution is to cache translations, rather than to discard the isolation provided by translation.

10. The TLB remembers translations

A translation lookaside buffer, or TLB, caches translations and associated access information. It stores the answer to “which frame and permissions apply to this virtual page in this address space?” A data cache instead stores instruction or data bytes. A processor may use both mechanisms during one access, but a hit in one does not logically imply a hit in the other.

Use a toy TLB with two fully associative entries, LRU replacement and initially empty contents. All pages in the following trace are mapped and resident. “Old → new” lists the least recently used entry first. A hit changes recency; a miss may evict a cached translation without evicting the page’s data from RAM.

This trace has one hit and four misses. It has zero demand-paging faults under the stated resident-mapping assumption. The label “page 2” in this independent TLB exercise does not inherit the unmapped state from the earlier four-page translation exercise: each example states its own initial conditions. The supplied simulator uses the earlier table and therefore uses page 3 in its corresponding replacement trace.

Address-space identifiers can distinguish cached translations belonging to different processes. Without an appropriate context distinction, old translations must be invalidated when changing address spaces. Changes to permissions or mappings also require cached translations to remain consistent. The principle is that a cached decision must not outlive the state on which it depends.

11. Calculate access time under explicit assumptions

A latency calculation is meaningful only after the access model is stated. Assume a serial TLB lookup taking t = 1 ns, each memory access taking m = 100 ns, a one-level table, resident pages and no other caches. A hit costs t + m = 101 ns. A miss costs t + 2m = 201 ns because it reads one PTE before the data. With hit ratio h, the expected cost is h(t + m) + (1 − h)(t + 2m).

For h = 0.95, the calculation is 0.95 × 101 + 0.05 × 201 = 106 ns. If a source ignores TLB lookup time, its formula differs because its assumptions differ. Do not combine a hit cost from one model with a miss cost from another. Also keep the comparison baseline visible: slowdown relative to 100 ns is not the same percentage as slowdown relative to 101 ns.

These values illustrate the effect of translation caching. They are not benchmark predictions. Real processors have cache hierarchies, page-walk caches, parallel activity and architecture-specific paths. An experiment that times a loop does not isolate TLB overhead simply because the loop touches memory.

12. Protection and sharing coexist

Translation answers where an access would go; protection answers whether the requested operation is permitted. A frame number alone does not authorize a write. Cached translations must retain or enforce the relevant permission information, so a TLB hit is not a way around protection. The supplied simulator makes this visible by reading a read-only page and then attempting a write that hits the cached translation.

The word “valid” is used in different teaching models. In this source figure it marks whether a page belongs to the logical address space. A separate residency model asks whether a legal page currently has a usable physical frame. Real architectures encode state in their own way. Ask what a bit means before deciding whether the right response is rejection, a table walk or a page-fault service operation.

Suppose process A maps virtual page 1 to frame 9 read-only, while process B maps virtual page 7 to frame 9 read/write. With 4096-byte pages, A’s 0x1234 and B’s 0x7234 both reach physical 0x9234. A cannot write through its mapping, but B can write through its own. Read-only for one mapping does not make the physical frame immutable to every participant.

13. Sparse address spaces and multilevel tables

A 32-bit byte address space with 4096-byte pages has 2²⁰ virtual pages. At four bytes per entry, a full linear table occupies 2²² bytes, or 4 MiB, per address space. Much of that table may describe unused ranges. Hierarchical tables make it possible to omit lower-level structures for large unmapped regions.

For a two-level 32-bit model with 4 KiB table pages and four-byte entries, a table page contains 1024 entries. Split the virtual address into a 10-bit outer index, a 10-bit inner index and a 12-bit offset. The outer entry locates an inner table; the inner entry locates the data frame. This split follows from the selected sizes, not from the phrase “two-level” alone.

If only three distinct outer-index regions need leaf tables, this model allocates one root page and three leaf pages: 16 KiB of table storage. A fully populated hierarchy needs 1025 table pages, slightly more than a linear table’s 1024 pages. The benefit depends on sparsity. Count the tables actually allocated; do not assume a hierarchy is always smaller.

14. Large spaces, alternative tables and page sizes

Increasing the virtual address width makes a flat table grow rapidly. A hypothetical full 64-bit byte space with 4 KiB pages has 2⁵² possible entries. Real implementations can support fewer virtual address bits than the register width, and virtual and physical widths can differ. Treat a large-space arithmetic example as a model unless a particular architecture and mode are specified.

Hashed tables organize candidate mappings by a hash of the virtual page identity. Collisions require comparing keys. Inverted tables organize information around physical frames, reducing dependence on the size of the virtual space but complicating lookup and shared mappings. These alternatives demonstrate representation trade-offs; they are not interchangeable descriptions of every operating system.

Page size also affects translation. A toy TLB with 64 entries covers at most 256 KiB with 4 KiB pages, or 128 MiB with 2 MiB pages, if each entry maps one page of that size. This nominal reach is not a promise that every access will hit. Larger pages can reduce table entries and increase reach, while smaller pages can reduce unused space and provide finer granularity.

15. Relate the model to Linux carefully

Linux kernel documentation describes a software page-table hierarchy named PGD, P4D, PUD, PMD and PTE. Unused levels can be folded to match an architecture. The five names therefore do not establish that every load on every Linux system performs five hardware table accesses. The architecture, enabled mode and kind of leaf mapping matter. See the kernel page-table documentation for the implementation vocabulary.

The historical Intel examples in the source explain segmentation followed by paging. They are useful for distinguishing logical, linear and physical addresses. Solaris and older ARM examples likewise illustrate specific designs. Their fixed widths and page sizes should not be treated as current universal limits. In particular, keep Intel 64 / x86-64 terminology distinct from IA-64.

On Linux, /proc/PID/maps describes mapped virtual regions and access permissions. Its address interval has an exclusive upper endpoint. Permissions include read, write and execute, with private/shared mapping information. This file does not provide a direct physical-frame mapping or prove that every page in a range is resident. Consult proc_pid_maps(5) when interpreting fields.

Whole-process swapping is another historical model: transfer an image out and later restore it, with relocation determining whether it must return to the same place. Page-level movement gives finer control. Week 6 will examine demand paging, replacement, copy-on-write, locality and thrashing; the present chapter supplies the translation and permission framework they require.

16. Optional practice: predict, observe and explain

The two small C programs below support optional study, not a new graded assignment. AI assistance is permitted. Use it to propose predictions or locate mistakes, then verify the explanation against the model, source code and output. Preserve the exact source and commands you used. A plausible explanation is not a substitute for tracing the computation.

Download translate.c. This deterministic simulator uses the four-page table from Section 8, 4096-byte pages and a two-entry fully associative LRU TLB. All mapped pages are resident. Successful accesses update recency; rejected accesses leave the cache unchanged. It does not read the host’s physical page tables or simulate disk-backed faults.

cc -std=c11 -Wall -Wextra -Werror -O2 translate.c -o translate
./translate

Before running, write down page number, offset, TLB contents and result for each source-code call. The successful reference pages are 0, 1, 0, 3, 1. Then a write to page 1 tests permission enforcement on a TLB hit. Finally pages 2 and 4 test rejection of an unmapped page and an address beyond the table. These cases check different boundaries.

Download address-view.c. This program prints its PID, base page size and addresses of a static object, an automatic object and a dynamically allocated object. On Linux it also reads its own /proc/self/maps, so the pointer values and map belong to the same process. This avoids accidentally inspecting a separate command’s address space.

cc -std=c11 -Wall -Wextra -Werror -O2 address-view.c -o address-view
./address-view
./address-view
uname -a
cc --version

Find the interval containing each printed pointer and explain its permissions. Compare runs without assuming that an object must appear at a fixed address or that every allocation must belong to a region labeled [heap]. Use sysconf(_SC_PAGESIZE) to discover the base page size; do not substitute the lecture’s 4096-byte model for the machine’s reported value.

The programs were compiled and executed on the preparation host, macOS, with strict warnings. The simulator’s full output was checked. The Linux-specific maps branch has not been executed on Ubuntu during preparation; students should record their Ubuntu observations and any environment restrictions. Native pointers and maps reveal virtual layout, not a physical frame number or a TLB hit rate.

17. Textbook figures for comparison

These original illustrations extend the chapter’s worked explanations. First identify the input address, the fields used to index a table and the unchanged offset. For the Intel and ARM examples, keep the named historical model separate from the configuration of the machine you inspect.

Page-number and offset fields

Associative translation lookup

A two-level split for a 64-bit model

IA-32 segment selector

IA-32 page-address fields

IA-32 translation stages

IA-32 segmentation

IA-32 paging alternatives

IA-32 physical address extension

A four-level x86-64 model

Historical ARM page and section mappings

18. Review, references and preparation for Week 6

Practice explaining one access from start to finish: identify the address space, divide the address, resolve the mapping, check the requested operation and form the physical result. Then add a TLB and distinguish a cached answer from the authoritative mapping. Finally replace the linear table with a hierarchy and count the structures and accesses under stated assumptions.

Keep a study sheet containing one allocation trace, one boundary translation, one permission failure, one TLB trace and one two-level walk. For each, write the initial state and assumptions before the result. Next week changes the resident-page assumption: what happens when the requested legal page has no immediately usable frame?

1. Silberschatz, Galvin and Gagne, Operating System Concepts, 10th edition, Chapter 9: §9.1 Background; §9.2 Contiguous Memory Allocation; §9.3 Paging; §9.4 Structure of the Page Table; §9.5 Swapping. Architecture examples in §§9.6–9.7 are contextual references. Adapted explanations and original figures are credited throughout. Official slide source.
2. Mehmet Göktürk, historical BIL601 memory-management lecture: segmentation hardware and example figures, adapted from the textbook tradition. Historical platform details are distinguished from current implementation claims.
3. Arpaci-Dusseau and Arpaci-Dusseau, OSTEP: Paging: Introduction, Paging: Faster Translations, and Paging: Smaller Tables.
4. Linux kernel: Page Tables; proc_pid_maps(5); sysconf(3). Implementation references checked during preparation, 21 October 2026.