Operating Systems

Start Lecture #15

Chapter 3 Memory Management

Also called storage management or space management.

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).
  • Prefetch
    • 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 level. This is normally called evicting the data (from the higher level).
• In OS classes we concentrate on the central-memory/disk layers and transitions.
• 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 decision:

1. Should we have segmentation.
2. Should we have paging.
3. 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 the program.
  • 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).

Homework: What is the difference between a physical address and a virtual address?

When is address translation performed?

1. At compile time
   • Compiler generates physical addresses.
   • Requires knowledge of where the compilation unit will be loaded.
   • No linker.
   • Loader is trivial.
   • Primitive.
   • Rarely used (MSDOS .COM files).
   
   
2. At link-edit time (the linker lab)
   • Compiler
     • Generates relative (a.k.a. relocatable) addresses for each compilation unit.
     • 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. Linker lab 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.
   
   
3. 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.
   
   
4. At execution time
   • Addresses translated dynamically during execution.
   • Hardware needed to perform the virtual to physical address translation quickly.
   • Currently dominates.
   • Much more information later.

Extensions

1. 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 it is.
   • This procedure slows down all calls to the routine (not just the first one that must load the module) unless you rewrite code dynamically.
   • Not used much.
   
   
2. 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 not move.

The sum of the memory requirements of all jobs in the system cannot exceed the size of physical memory.

Monoprogramming

The 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.
  • A 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 The 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.