A-Level · Computer Systems · OCR-only

Memory Management

How an operating system lets a dozen programs, each written as if it owned all of memory, actually share a fixed amount of RAM safely. Every diagram below is a real, live picture of memory, not a description of one.

Section 2

Paging: fixed-size blocks and address translation

On the left, a program's virtual pages. On the right, actual physical RAM frames. The lines between them are the page table, made visible. Translate an address and watch the exact page, line, and frame light up.

Translate a virtual address (page size = 256 bytes)

Try one

Exam tips

  • Virtual address = page number + offset, found by integer-dividing by the page size (page number) and taking the remainder (offset). Only the page number changes in translation, the offset carries straight across, visible directly in the diagram, the highlighted position within the frame matches its position within the page.
  • Page 4 has no line connecting it to anything, that absence is the page fault. There's no physical frame to jump to, so the CPU has to stop and wait for the OS to fetch it from secondary storage.
Section 3

Segmentation: variable-sized logical blocks

Rather than fixed-size pages with no relationship to the program's structure, segmentation divides memory along logical lines the programmer actually recognises: code, data, stack.

Physical memory layout (proportional to actual size)

Each segment has a base address and a length (limit), both visible directly in the bar's width and position above. An address within a segment is checked against that limit, an offset beyond it is an illegal access, caught before it can read or corrupt another segment's memory.

Paging vs Segmentation

PropertyPagingSegmentation
Block sizeFixed (e.g. 256 bytes)Variable, matches logical units
Fragmentation riskInternal (last page often part-empty)External (gaps between variable blocks)
Programmer awarenessInvisible to the programmerCan reflect the program's own structure
Address formPage number + offsetSegment number + offset
Section 4

Page replacement: FIFO vs LRU

RAM can't hold every page at once. When it's full and a new page is needed, something has to be evicted, watch it happen, not just read about it.

Reference string (current access highlighted)

Physical frames (3 available)

Fault count so far

0

Exam tips

  • FIFO evicts whichever page has been in memory longest, regardless of how recently it was actually used. LRU evicts whichever page hasn't been accessed for the longest time.
  • Run this exact reference string on both algorithms and compare the two final fault counts, the result may not be what you'd expect. Real-world performance depends entirely on the actual access pattern, not on which algorithm sounds more sophisticated.
Section 5

Virtual memory: three processes, one small RAM

Three processes, 8 virtual pages between them, but only 4 physical frames exist. Click any page to access it. Watch RAM genuinely fill up, and watch exactly which page lands in secondary storage the moment something has to move out.

Physical RAM (4 frames)

Secondary Storage (disk)

Click any page below (from any process) to access it. Green means in RAM right now, orange means currently sitting on disk, watch the disk panel on the right update the moment a page actually moves there.

Benefit vs cost, made concrete by what you just saw

  • Benefit: all three processes above can keep running, none of them ever "run out of memory", even though 8 virtual pages genuinely cannot all fit in 4 physical frames at once.
  • Cost: every time you clicked a page that was on disk, that access had to wait for a disk fetch, genuinely orders of magnitude slower than RAM. A process that keeps needing pages currently evicted (thrashing) spends more time swapping than doing useful work.
Section 6

Check your understanding