Virtual Memory amp;Address Translation.ppt

Oct 9, 2001 Virtual Memory Translation Virtual Memory Address Translation Vivek Pai Princeton University General Memory Problem We have a limited (expensive) physical resource: main memory We want to use it as efficiently as possible We have an abundant, slower resource: disk Lots of Variants Many programs, total size less than memory Technically possible to pack them together Will programs know about each other’s existence? One program, using lots of memory Can you only keep part of the program in memory? Lots of programs, total size exceeds memory What programs are in memory, and how to decide? History Versus Present History Each variant had its own solution Solutions have different hardware requirements Some solutions software/programmer visible Present – general-purpose microprocessors One mechanism used for all of these cases Present – less capable microprocessors May still use “historical” approaches Many Programs, Small Total Size Observation: we can pack them into memory Requirements by segments Text: maybe contiguous Data: keep contiguous, “relocate” at start Stack: assume contiguous, fixed size Just set pointer at start, reserve space Heap: no need to make it contiguous Many Programs, Small Total Size Software approach Just find appropriate space for data code segments Adjust any pointers to globals/functions in the code Heap, stack “automatically” adjustable Hardware approach Pointer to data segment All accesses to globals indirected One Program, Lots of Memory Observations: locality Instructions in a function generally related Stack accesses generally in current stack frame Not all globals used all the time Goal: keep recently-used portions in memory Explicit: programmer/compiler reserves, controls part of memory space – “overlays” Note: limited resource may be address space Many Programs, Lots of Memory Software approach Keep only subset of programs in memory When loading a program, evict any programs that use the same memory regions “Swap” programs