Wednesday, October 13, 1993
-------------------------------------------------------------------------------
Announcements:
	Answers to problems available in copy center, first floor HRBB
	Wednesday, October 20: plan to meet in HRBB 131
	Schedule reminders: Friday, exam review; Monday, midterm
-------------------------------------------------------------------------------
Today: Memory Management (Chapter 7)
-------------------------------------------------------------------------------
- Goal: permit different processes to share memory---effectively keep several
in memory at the same time
- Meta goal: user develops program in what appears to be their own infinitely
large address space (e.g., starting at address 0 and extending without limit)
- Note that entire program assumed to be in physical memory before program can
execute (later will see schemes to permit partial residency---e.g., paging)
- Note interaction with hardware and resource characteristics---hierarchical
storage organization: program and data must be in primary memory to be
referenced by CPU directly; access time less in primary memory; limited size
primary memory because primary memory much more expensive than secondary
memory;
-------------------------------------------------------------------------------
Multistep processing of user program (figure 7.1, text)

        -(Source program)
Compile |			Compiler or assembler
        -(Object module) [+other object modules]
        |			linkage editor
Load    |(Load module) [+system library routines]
Time    |			loader
        -(executable memory image) [+dynamically loaded system library]
Run     |			execution
Time

*Binding* of instructions and data to physical memory addresses
- Binding: associate location with object in program.  Mapping of one address
space to another.  (Other things can be bound in programming language; we are
concentrating on addresses now.)
- typically, compiler binds symbolic names (e.g., variable names) to
relocatable addresses (e.g., relative to start of module); linkage editor may
further modify relocatable addresses; loader binds relocatable addresses to
absolute addresses
- But address binding can actually be done at any point in design:
= binding at *compile time*
	- Generating absolute code.  Must know at compile time where process
	(or object) will reside in memory.  What is *0 in C?
	- Mostly appropriate for small, simple systems (or dedicated hardware)
= binding at *load time*
	The most common case.  Compiler generates relocatable addresses which
	become absolute addresses at load time.  Program cannot be moved around
	during execution.  Change of starting address accomplished by reloading
	code.  Simple but can be inconvenient.
= binding at *run time*
	Permits moving process during run time from one *memory segment* to
	another.  Hardware assistance required (discussed later) and also
	run-time overhead results from movement of process.
-------------------------------------------------------------------------------
Dynamic loading
- straightforward scheme loads all routines before runtime starts
- dynamic loading: load routine on its first use
- on call to routine: check if it is in memory; if not load it
- note that unused routine not loaded (as opposed to static case where we can
avoid loading *unreferenced* library routines---can't avoid loading all
*unused* routines when static)
-------------------------------------------------------------------------------
Dynamic linking
- similar to dynamic loading in concept
- postpone linking library routines until runtime
- library routines *not* present in executable image. Instead stubs are present
- implementation is that stub replaces itself with address of
memory-resident library routine when routine is used
- hence can have all routines referencing library use the *same*
memory-resident copy of the library routine
- savings of overall memory (one copy of library routine) and disk
space (library routines not in executable image)
- can retain version number to distinguish incompatible versions of
library (or can require upward compatibility in library routines)
- if different versions distinguished then can have different versions
in memory at same time.
- example: SUN OS's shared libraries
-------------------------------------------------------------------------------
Overlays
- permits process to be larger than amount of memory allocated to it.
- keeps in memory only those instructions and data in current use
- needed instructions and data replace those no longer in use
- for example
			common data
			common routines
			overlay driver
	routineA--->	overlay area	<---routineB
  Where routineA might create a data structure and routineB might perform
  further transformations on it (e.g., a compiler or an assembler).
- no special hardware support required
- programmer must structure program appropriately (may be difficult).
Ad hoc solution
-------------------------------------------------------------------------------
Swapping
- What: temporarily move inactive process to *backing store* (e.g.,
 	fast disk)
        return to main memory for continued execution
- Why: permit other processes to use memory resources (so they can be bigger)
- When: perhaps start to swap out when quantum expires and swap in
another process with the goal of having it in place when the currently
executing process' quantum expires (overlap computation with disk i/o)
- context switch time is very high if you can't achieve this
- maybe *roll out* lower priority process in favor of higher priority
process. *roll in* lower priority process when higher finishes
- if static address binding (compile or load time binding) have to
swap process back into *same memory space*
- If execution time address binding then can swap back into different
memory space
- disk is slow and transfer time is proportional to size of process so
useful if process can specify that you aren't using all of allocated memory
- Process cannot be swapped until completely idle---consider overlapped DMA i/o
(have to have buffer space in memory when i/o request comes back)
- Swapping in this form (e.g., this large granularity) not very common now.
-------------------------------------------------------------------------------