1
- 1
13: Memory Management
Last Modif ied: 6/ 21/ 2004 9:51:29 AM
- 2
Recall: Address Space Map
St ack
(Space f or local var iables et c. For each nest ed pr ocedur e call)
Heap
(Space f or memor y dynamically allocat ed e.g. wit h malloc)
St at ically declar ed var iables
(Global var iables)
Code
(Text Segment )
St ack Point er PC Ox0000 Biggest Vir t ual Address Somet imes Reserved f or OS Somet imes Reserved f or Error Cat ching
- 3
P rocesses Address Space
Logically all of t his address space should
be resident in physical memory when t he pr ocess is r unning
How many machines do you use t hat have
232= 4 GB of DRAM? Let alone 4 GB f or *each* process!!
- 4
Let ’s be reasonable
Does each process really need all of t his
space in memory at all t imes?
Fir st has it even used it all? lot s of r oom in t he
middle bet ween t he heap gr owing up and t he st ack gr owing down
Second even it has act ively used a chunk of t he
addr ess space is it using it act ively r ight now
- May be lot s of code t hat is rarely used (init ializat ion
code used only at beginning, error handling code, et c.)
- Allocat e space on heap t hen deallocat e
- St ack grows big once but t hen normally small
- 5
Freeing up Syst em Memory
What do we do wit h por t ions of addr ess space
never used?
Don’t allocat e t hem unt il t ouched!
What do we do wit h r ar ely used por t ions of t he
addr ess space?
This isn’t so easy J ust because a variable rarely used doesn’t mean t hat we
don’t need t o st ore it s value in memory
St ill it ’s a shame t o t ake up precious syst em memory wit h
t hings we are rarely using! (The FS could sure use t hat space t o do caching remember?)
What could we do wit h it ?
- 6
Send it t o disk
Why couldn’t we send it t o disk t o get it
- ut of our way?
I n t his case, t he disk is not r eally being used
f or non-volat ile st or age but simply as t empor ar y st aging ar ea
What would it t ake t o r est or e r unning