© 2004, D. J. Foreman 1

Memory Management

© 2004, D. J. Foreman 2

Building a Module -1Compiler

■ generates references for function addresses• may be inside current file

• may be external - in a separate compile

■ addresses are 'marked' in compiler output- the "object" file

Linker or Link Editor■ Resolves addresses (references)■ Makes them relative to start of module■ Saves relocatable module

© 2004, D. J. Foreman 3

Building a Module -2 Loader

■ Builds a table of addresses (ref table)• References • Definitions

■ replaces every relative address with sum of actual load address + relative address

■ gives control to the module■ original relocatable file is still on disk

This is called "static binding" of the logical address to the physical address

© 2004, D. J. Foreman 4

Building a Module -3Dynamic memory - malloc, etc

■ Linker examines all calls to malloc■ Adds up requests (as much as possible)■ Adds space for stack data

Loader assigns space for both■ Heap space allocated from one end of block■ Stack space allocated from other end■ Grow toward middle

Ask O/S for more, when space is gone

© 2004, D. J. Foreman 5

StrategiesFixed-size partition

■ Divide all RAM into N blocks■ Program size must be < block size■ Internal fragments exist - cannot be used

Variable-size partition■ Blocks defined as needed

• Must keep track of blocks• External fragmentation occurs and gets worse

– Smaller holes left, as processes fill old holes– Favors smaller and smaller processes

• Eventually must move processes

© 2004, D. J. Foreman 6

Managing fragmentsMove programs - compactionAllocation strategies

■ Best fit - search for block with closest size■ Worst fit - find biggest block - leaves largest

hole when program terminates■ First fit - use first hole in list, from front■ Next fit - circular list, just use next entry in list

Part of block points to next■ Helps manage 'garbage collection' - the

process of building big blocks from little ones

© 2004, D. J. Foreman 7

Current StrategiesAll use variable-sized partitionsMost use fixed sized blocks within the

partition - will be called pagesSimplifies list mgmt

Other considerations:■ Program segments don't (usually) change size■ If pgm seg changes size, pgm must be moved■ Loader must re-bind - increases overhead

© 2004, D. J. Foreman 8

Dynamic BindingAll addresses are relative to "0"Adjust all addresses as in static bindingRepeat when moving programCan be done with h/w relocation registerSimple relocation done easilyh/w adjusts every memory referenceRelocation value added as needed

© 2004, D. J. Foreman 9

Improvements Multiple relocation registers

■ Code segment register - during fetch cycle■ Stack segment register - for stack instructions■ Data segment register - during execute cycle

Automatic relocation-register management■ Compiler generates code to update register when

references cross segment boundary■ No auto-help for

• Assembler programs

• Programs with data segments > register capability

• Programs that change segment registers

© 2004, D. J. Foreman 10

Making it workTrusted s/w for register manipulation

■ Privileged instructions■ Compiler generates a segment trap■ NOT a violation trap■ O/S changes the relocation registers■ O/S changes the Program Counter

• Also privileged

■ Program proceeds

© 2004, D. J. Foreman 11

IsolationNeed to ensure access protection"Limit register" added

■ Contains length of segment■ Compute: segment register + relative address■ If relative address <= limit then proceed■ Else segment fault (protection error)

© 2004, D. J. Foreman 12

SwappingSwapping removes the entire address

spaceCost analysis:

■ If a process has S memory space units■ And a disk block holds D memory units ■ K=Ceil (S/D) disk writes required to save ■ And K reads to restore it later = 2*K overhead

■ If Pi is blocked for T time, cost = T*S

■ T must be > X (assume 1 I/O = 1 Time unit)

© 2004, D. J. Foreman 13

Another strategySwapping removes an entire processWhat if we only remove specific blocks?Must recognize spatial localitySometimes called locality of referenceAnd temporal localityWe can remove/restore selected pages

© 2004, D. J. Foreman 14

Virtual Memory MgmtResponsibilities:

■ Determine locality■ Keep referenced pages in memory

Problems:■ Partitioning■ Scatter-loading■ Re-binding■ Architecture ■ Construction■ Actual

© 2004, D. J. Foreman 15

Shared MemoryMultiprocessors need to shareIncreases bus load, reduces speedSpeedup via cache, but new problems:

■ Stale data (coherency)■ Expense

Interconnection networks:■ More speed■ More expense

• Must detect changes everywhere• Must force cache update synch