Lecture 10 Memory allocation

Lecture 10 Memory allocation - Administrivia Project 2 due...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Administrivia Project 2 due right now- As before, free extension if you are here- For SCPD students, put this at top of design doc: caf656- For non-SCPD students, put this: Midterm Tuesday- Open book, open notes (but not open notebook computer)- Covers first 10 lectures of course (including today) Midterm review section tomorrow Section for Project 3 next Friday I will monitor newsgroup/list for questions- Please put [midterm] in subject of questions about midterm 1/36 Dynamic memory allocation Almost every useful program uses it- Gives wonderful functionality benefits Dont have to statically specify complex data structures Can have data grow as a function of input size Allows recursive procedures (stack growth)- But, can have a huge impact on performance Today: how to implement it- Lecture draws on [Wilson] (good survey from 1995) Some interesting facts:- Two or three line code change can have huge, non-obvious impact on how well allocator works (examples to come)- Proven: impossible to construct an always good allocator- Surprising result: after 35 years, memory management still poorly understood 2/36 Why is it hard? Satisfy arbitrary set of allocation and frees. Easy without free: set a pointer to the beginning of some big chunk of memory (heap) and increment on each allocation: Problem: free creates holes (fragmentation) Result? Lots of free space but cannot satisfy request! 3/36 More abstractly What an allocator must do:- Track which parts of memory in use, which parts are free- Ideal: no wasted space, no time overhead What the allocator cannot do:- Control order of the number and size of requested blocks- Change user ptrs = (bad) placement decisions permanent The core fight: minimize fragmentation- App frees blocks in any order, creating holes in heap- Holes too small? cannot satisfy future requests 4/36 What is fragmentation really? Inability to use memory that is free Two factors required for fragmentation- Different lifetimesif adjacent objects die at different times, then fragmentation:- If they die at the same time, then no fragmentation:- Different sizes: If all requests the same size, then no fragmentation (thats why no external fragmentation w. paging): 5/36 Important decisions Placement choice: where in free memory to put a requested block?- Freedom: can select any memory in the heap- Ideal: put block where it wont cause fragmentation later (impossible in general: requires future knowledge) Split free blocks to satisfy smaller requests?- Fights internal fragmentation- Freedom: can chose any larger block to split- One way: chose block with smallest remainder (best fit) Coalescing free blocks to yield larger blocks- Freedom: when to coalesce (deferring can be good) fights external fragmentation 6/36 Impossible to solve fragmentation If you read allocation papers to find the best allocator- All discussions revolve around tradeoffs...
View Full Document

Page1 / 39

Lecture 10 Memory allocation - Administrivia Project 2 due...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online