Introduction to Memory Management

Objectives

1. Understand the basic hardware involved with memory

Notes

• This is chapter 9.1/9.2
• Outcome: Analyze and compare memory management methods and policies.
• Outline
  • physical vs. virtual memory and memory management hardware
  • overlays, swapping and partitions
  • paging and segmentation
  • placement and replacement policies: FIFO, LRU, LFU, NUR
  • working sets and thrashing
  • caching
• Since I am becoming the hardware person I really need a memory review.
• Memory is a large array of bytes, each with an address
  • We say that it is byte addressable.
• CPU fetches instructions and data from memory
  • fetch-decode-execute
  • But memory doesn't know or care where the load/store came from
• What we know from architecture
  • Instructions, or micro instructions transfer data between registers in the cpu.
  • These registers operate at the clock rate (possibly sub clock rate)
  • But memory does not operate at this speed.
    • Cache is an attempt to mitigate this
    • Cache is generally under the control of the hardware. (cache algorithms are hard coded)
• The OS needs to protect memory
  • It employs whatever hardware it has to do this.
  • For an example, consider two registers
    • The base register points to the lowest memory a process has access to.
    • The limit register holds the amount of memory a process has access to.
    • See Figure 9.1 on page 351.
    • Any memory access must be: Base Register ≤ address ≤ Base Register + Limit Register
    • In this scenario the CPU has hardware that checks this and any access outside this range results in a call to the kernel.
    • Clearly these registers can only be modified by the kernel in protected mode.
    • In protected mode, the kernel has access to all of the system's memory.
      • It can load a program's memory as it becomes a process
      • It can change parameters for system calls.
      • And other tasks.
• Ok so I see a problem:
  • My code loads and stores to exact memory locations.
  • But the last pictures showed that my code could actually reside anywhere
  • So how can my program move all over the place?
• Well, the question is actually a lie
  • Addresses are generally symbolic in the source code.
  • The compiler/assembler binds these addresses to relocatable addresses in the object files
    • The book mentions 14 bytes from the beginning of the data segment.
    • Or even PC + 16 bytes for a jump.
  • The linker preserves these and links in relative addresses of library functions.
  • The loader then binds these relocatable addresses to absolute addresses when the program is loaded (becoming a process).
  • This process may vary by OS and Hardware.
• He lists three different ways to bind addresses
  1. At compile time, if you know where you will go.
     • Probably ancient or very specialized hardware.
     • Recompile is necessary if things move.
  2. At load time
     • This was described above.
     • relocatable code.
  3. At execution time
     • If the process can be moved while executing special hardware is required.
     • This is what most modern OS's use.
• To accomplish execution time addressing we view addresses in two spaces
  • Logical address space, or logical addresses are the ones in the program.
    • Probably 0 through n
    • This is also called the virtual address.
  • But physical address space is the actual address in memory or the physical address.
  • Hopefully every CPU picture you have seen includes a MMU, or Memory Management Unit.
    • This performs a mapping from virtual to physical addresses.
  • The easiest way to do this is through a reallocation register which contains the mapping from 0 virtual to the actual physical address.
  • But there are other methods we will discuss later.
• In the simple scheme
  • The logical address is written to the MAR
  • The MMU adds the value of the relocation register to this to get the physical address
  • Which is used to fetch/store the data.
  • See Fig 9.5 page 335 if you must.
• Dynamic Libraries
  • The linker does not import library code into the executable.
    • I probably gave you this impression in 230, but
    • That would lead to the bloat of executable files.
    • And also the code segment of every process.
  • Instead, libraries are loaded dynamically
    • When a shared library is needed
      • Check to see if it is already loaded, if so use it.
      • If not, load it.
    • Dynamic shared libraries can be shared between multiple processes.
  • Dynamic and shared are different concepts, but the author tells us that most modern OS's use both.
  • And that shared libraries require OS support while dynamic libraries do not.