Start Lecture #15
Chapter 3 Memory Management
Also called storage management or
The memory manager must deal with the
storage hierarchy present in modern machines.
- The hierarchy consists of registers (the highest level),
cache, central memory, disk, tape (backup).
- Various (hardware and software) memory managers moves data
from level to level of the hierarchy.
- We are concerned with the central memory ↔ disk boundary.
- The same questions are asked about the cache ↔ central
memory boundary when one studies computer architecture.
Surprisingly, the terminology is almost completely different!
- When should we move data up to a higher level?
- Fetch on demand (e.g. demand paging, which is dominant now
and which we shall study in detail).
- Read-ahead for file I/O.
- Large cache lines and pages.
- Extreme example.
Entire job present whenever running.
- Unless the top level has sufficient memory for the entire
system, we must also decide when to move data down to a lower
This is normally called evicting the data (from the higher
- In OS classes we concentrate on the central-memory/disk layers
- In architecture we concentrate on the cache/central-memory
layers and transitions (and use different terminology).
We will see in the next few weeks that there are three independent
- Should we have segmentation.
- Should we have paging.
- Should we employ fetch on demand.
Memory management implements address translation.
- Convert virtual addresses to physical addresses
- Also called logical to real address translation.
- A virtual address is the address expressed in
- A physical address is the address understood
by the computer hardware.
- The translation from virtual to physical addresses is performed by
the Memory Management Unit or (MMU).
- Another example of address translation is the conversion of
relative addresses to absolute addresses
by the linker.
- The translation might be trivial (e.g., the identity) but not
in a modern general purpose OS.
- The translation might be difficult (i.e., slow).
- Often includes addition/shifts/mask—not too bad.
- Often includes memory references.
- VERY serious.
- Solution is to cache translations in a
Translation Lookaside Buffer (TLB).
Sometimes called a translation buffer (TB).
What is the difference between a physical address and a virtual address?
When is address translation performed?
- At compile time
- Compiler generates physical addresses.
- Requires knowledge of where the compilation unit will be loaded.
- No linker.
- Loader is trivial.
- Rarely used (MSDOS .COM files).
- At link-edit time (the
- Generates relative (a.k.a. relocatable) addresses for each
- References external addresses.
- Linkage editor
- Converts relocatable addresses to absolute.
- Resolves external references.
- Must also converts virtual to physical addresses by
knowing where the linked program will be loaded.
does this, but it is trivial since we
assume the linked program will be loaded at 0.
- Loader is still trivial.
- Hardware requirements are small.
- A program can be loaded only where specified and
cannot move once loaded.
- Not used much any more.
- At load time
- Similar to at link-edit time, but do not fix
the starting address.
- Program can be loaded anywhere.
- Program can move but cannot be split.
- Need modest hardware: base/limit registers.
- Loader sets the base/limit registers.
- No longer common.
- At execution time
- Addresses translated dynamically during execution.
- Hardware needed to perform the virtual to physical address
- Currently dominates.
- Much more information later.
Note: I will place ** before each memory management
- Dynamic Loading
- When executing a call, check if the module is loaded.
- If it is not loaded, have a linking loader load it and
update the tables to indicate that it now is loaded and where
- This procedure slows down all calls to the routine (not just
the first one that must load the module) unless you rewrite
- Not used much.
- Dynamic Linking.
- This is covered later.
- Commonly used.
3.1 No Memory Management
The entire process remains in memory from start to finish and does
The sum of the memory requirements of all jobs in the system cannot
exceed the size of physical memory.
good old days when everything was easy.
- No address translation done by the OS (i.e., address translation is
not performed dynamically during execution).
- Either reload the OS for each job (or don't have an OS, which is almost
the same), or protect the OS from the job.
- One way to protect (part of) the OS is to have it in ROM.
- Of course, must have the OS (read-write) data in RAM.
- Can have a separate OS address space that is accessible
only in supervisor mode.
- Might put just some drivers in ROM (BIOS).
- The user employs overlays if the memory needed
by a job exceeds the size of physical memory.
- Programmer breaks program into pieces.
root piece is always memory resident.
- The root contains calls to load and unload various pieces.
- Programmer's responsibility to ensure that a piece is already
loaded when it is called.
- No longer used, but we couldn't have gotten to the moon in the
60s without it (I think).
- Overlays have been replaced by dynamic address translation and
other features (e.g., demand paging) that have the system support
logical address sizes greater than physical address sizes.
- Fred Brooks (leader of IBM's OS/360 project and author of
mythical man month) remarked that the OS/360 linkage editor was
terrific, especially in its support for overlays, but by the time
it came out, overlays were no longer used.