MEMORY MANAGEMENT

compiler compiles program code and data and makes a guess about how big a heap and stack the program will need as it executes

the total size N of code, data, guessed heap, and guessed stack is put into the executable file produced by the compiler

the compiler has no idea about what actual physical RAM addresses the program will occupy as it runs so the compiler assumes the program will start at RAM address 0 through total (guessed) size N

the role of the memory manager is to map the process address space (code, data, heap, stack running from pretend addresses 0 to N-1) into actual RAM addresses M₁ to M₂

static (loadtime) binding (relocation): rewrite all addresses in the compiler-produced code by adding M₁

• no hardware memory protection provided
• process cannot be moved once it has been loaded into RAM and all compiler-generated addresses adjusted
• if process is swapped out, it must be swapped back into the exact same locations in RAM

dynamic (runtime) binding (relocation): use base and limit registers, base = M₁, limit = N = M₂ - M₁ + 1

• hardware memory protection provided
• process can be moved once it has been loaded into RAM, just change to base register value accordingly
• if process is swapped out, it can be swapped back into RAM anywhere it will fit, just change to base register value accordingly

schemes to manage free areas of RAM to allocate for new processes

fixed number of partitions of fixed sizes

• static (loadtime) binding (relocation)
• assign a new process a big enough partition
• process is allocated the whole partition no matter how much is unused, called fragmentation (later called external fragmentation to distinguish it from a form of fragmentation coming up soon called internal fragmentation)
• very old scheme, inflexible, only so many processes can run simultaneously even if lots of RAM unused
• if a process is swapped out, it must be swapped back into the exact same locations in RAM

variable number of partitions of variable sizes

• dynamic (runtime) binding (relocation) with base and limit registers
• hole list: linked list of nodes where each node contains beginning address of the hole, size of the hole, next pointer
• allocate new processes a big enough hole from the list: first fit, best fit, worst fit, next fit
• take allocation from the upper part of the hole and reduce the hole's size (or remove the hole from the hole list if the allocation is an exact fit)
• Tanenbaum mentions (on page 186 of 3^rd ed. MOS) a comparison published in 1977 that determined that next fit is slightly worse than first fit (hard to believe, isn't it!)

  Communications of the ACM
  Volume 20, Issue 3 (March 1977)
  Pages: 191--192
  Year of Publication: 1977
  ISSN: 0001-0782
  Author: Carter Bays, Univ. of South Carolina, Columbia
  Publisher: ACM, New York, NY, USA
  
  Use this link to bookmark this Article:
  http://doi.acm.org/10.1145/359436.359453
  
  "Next-fit" allocation differs from first-fit in that a first-fit allocator
  commences its search for free space at a fixed end of memory, whereas a
  next-fit allocator commences its search wherever it previously stopped
  searching.  This strategy is called "modified first-fit" by Shore [2] and
  is significantly faster than the first-fit allocator.  To evaluate the
  relative efficiency of next-fit (as well as to confirm Shore's results)
  a simulation was written in Basic Plus on the PDP-11, using doubly
  linked lists to emulate the memory structure of the simulated computer.
  The simulation was designed to perform essentially in the manner described
  in [2].  The results of the simulation of the three methods show that the
  efficiency of next-fit is decidedly inferior to first-fit and best-fit
  when the mean size of the block requested is less than about 1/16 the
  total memory available.  Beyond this point all three allocation schemes
  have similar efficiencies.
  
  Figure 1 shows the mean request size for (truncated) exponentially
  distributed requests versus E, the time-memory product efficiency as
  defined in [2] (the plot essentially corresponds to Figure 2 in [2]
  although naturally all of the points are somewhat different). The total
  memory size was 32,768 and the memory-residence time of requests was
  uniformly distributed between 5 and 15 time units. Each point represents
  the mean of approximately 20 runs, where the clock time for each run
  varied from 500 to 5000.  The standard deviation of each point was
  less than .006.  The results of this simulation support the hypothesis
  mentioned by Shore, that "when first-fit outperforms best-fit, it does so
  because first-fit, by preferentially allocating [blocks] toward one end
  of memory, encourages large blocks to grow at the other end."  The fact
  that next-fit is decidedly inferior to both first-fit and best-fit implies
  that eliminating the preferential allocation of first-fit causes a loss
  of efficiency.
  
  REFERENCES
  
  1 Donald E. Knuth, The art of computer programming, volume 1 (3rd ed.):
  fundamental algorithms, Addison Wesley Longman Publishing Co., Inc.,
  Redwood City, CA, 1997
  
  2 John E. Shore, On the external storage fragmentation produced by
  first-fit and best-fit allocation strategies, Communications of the ACM,
  v.18 n.8, p.433-440, Aug. 1975
  

• merge or coalesce adjacent holes when a process exits; hole list is kept sorted by beginning address of the hole to facilitate this
• fragmentation still a problem if hole list becomes lots of small holes (external fragmentation)
• compaction possible but slow: seconds for a 256 MB RAM
• if heap and stack collide, cannot increase N and move process to a bigger hole since that would make all stack addresses incorrect
• if process is swapped out, it can be swapped back into RAM anywhere it will fit, just change to base register value accordingly

we have four restrictions or limitations limiting the flexibility of the memory manager

• whole program must be loaded into RAM for it to execute,
• program code-data-heap-stack must be loaded into one contiguous region of RAM,
• cannot increase the size of the stack if the heap and stack collide, and
• fragmentation (many small holes in the hole list) is a problem (external fragmentation)

to solve the heap-stack collision problem, modify the compiler so it divides a program it is compiling into two pieces, code-data-heap and stack, and produces two address spaces, code-data-heap from 0 to N₁-1 and stack from 2³¹ to 2³¹ + N₂-1, where N₁ and N₂ are still guessed by the compiler

turn stack rightside up and start it at 2³¹

starting the stack at 2³¹ gives the CPU a way to distinguish code-data-heap addresses from stack addresses

two base registers base_CDH and base_S in the CPU instead of one; two limit registers limit_CDH and limit_S in the CPU instead of one; two base values and two limit values instead of one stored in the process table PCB for each process

format of machine instruction reading or writing data-heap using an address field and base_CDH, limit_CDH for runtime hardware address translation

          register       32 bit compiler
           number        generated address
--------------------------------------------
|        |               |                 |
| opcode | Rx            | 0xxxxx...xxxxxx |
|        |               |                 |
--------------------------------------------

format of machine instruction reading or writing stack using an address field and base_S, limit_S for runtime hardware address translation

          register       32 bit compiler
           number        generated address
--------------------------------------------
|        |               |                 |
| opcode | Rx            | 1xxxxx...xxxxxx |
|        |               |                 |
--------------------------------------------

when program is to be executed, the memory manager finds two big enough holes for the two address space pieces

if the heap reaches its limit, copy the code-data-heap to a bigger hole and adjust base_CDH and limit_CDH

if the stack reaches its limit, copy the stack to a bigger hole and adjust base_S and limit_S

but we still have three restrictions or limitations limiting the flexibility of the memory manager that uses the hole list (of variable sized holes) and needs to find two holes from the hole list to execute a program for a user

1. whole program must be loaded into RAM for it to execute,
2. program code-data-heap and program stack must be loaded into two contiguous regions of RAM, and
3. fragmentation (many small holes in the hole list) is a problem (external fragmentation)

virtual memory implemented with paging eliminates the above three restrictions

here are some other concerns about RAM usage handled by virtual memory; the following are ways that an executing program, if loaded entirely in RAM when it begins executing, uses its RAM allocation inefficiently or wastefully

• if a program has declared array sizes to handle the biggest case, the program will never use some its RAM when executed with data that is smaller than the biggest case
• a program might never execute some of its code (and therefore never use some of its RAM), for example code that handles error situations that do not occur during a particular execution
• a program might execute some of its code at the beginning and then never execute that code again, for example code that checks the input data for validity; so some RAM is idle for the rest of the execution
• a program might not execute some of its code until the very end, for example code that formats the output data; so some RAM is idle
• a program's stack or heap might suddenly grow to a very large size for a short period of time and then shrink back; once the additional RAM is allocated for the heap or stack growing past the compiler's guess, the RAM stays allocated until the program terminates

if a program can execute without all of its code and data in RAM all the time, the OS memory manager can use RAM more efficiently; in other words, a process can its RAM allocation more efficiently or less wastefully

the following stuff is explained in more detail in the ``Paging Fact Sheet''

pages of code-data-heap and stack address spaces and page frames of RAM, all of size 2¹² = 4096 bytes

each process has two page tables inside OS RAM, one for code-data-heap and one for stack

• fields of each page table entry are PFN (page frame number), valid bit, modified bit, reference bit, 16 bit age field

OS hole list becomes list of free page frames

to run a process, OS need load only some of code-data-heap and stack pages into free page frames

address translation done by CPU hardware

          register            32 bit compiler
           number             generated address
                           1      19          12
-----------------------------------------------------
|        |               |   | xxxxxxxxxx  | xxxxxx |
| opcode | Rx            | y |             |        |
|        |               |   | page number | offset |
-----------------------------------------------------

• y is 0 or 1 for code-data-heap or stack address respectively
• use y to pick page table
• use page number to pick page table entry (if too big, memory fault)
• if valid bit == 1, extract PFN from page table entry
• concatenate or append offset bits onto right of PFN bits
• result is RAM address
• if valid bit == 0, hardware generates page fault interrupt

page fault handled by OS software (page fault interrupt handler)

• find a free page frame from the free list or do a page replacement
• update the affected process's page table entries

what if no free page frames on free page frame list?

• need to find a free page frame (free up a page frame) whose contents will be overwritten (replaced) with the missing page (that generated the fault)

local replacement, fixed allocation

• LRU (least recently used)
• too expensive to do exactly so use reference bit and 16-bit age field to approximate

global replacement, variable allocation

• clock algorithm, paging daemon, hand goes around scanning all allocated page frames, reclaiming least recently used page frames from processes if size of free page frame list gets uncomfortably small
• reclaimed page frames are written to the disk swapping area if dirty (modified)
• page table entries updated
• do the scanning until the size of the free page frame list gets comfortably large
• page faults are satisfied out of the free page frame list
• clock interrupts do the following to all valid page table entries of the currently executing process: right shift age field, copy reference bit into left most age field bit, zero out reference bit

external versus internal fragmentation

spatial and temporal locality

TLB (translation lookaside buffer)

factors affecting choice of page size

swapping area on disk

home page: http://elvis.rowan.edu/~hartley/index.html
e-mail: hartley@elvis.rowan.edu