Opera&ng Systems CMPSCI 377 Dynamic Memory Management. Emery Berger and Mark Corner University of Massachuse9s Amherst

Transcription

1 Opera&ng Systems CMPSCI 377 Dynamic Memory Management Emery Berger and Mark Corner University of Massachuse9s Amherst

2 Dynamic Memory Management How the heap manager is implemented malloc, free new, delete 2

3 Memory Management Programs ask memory manager to allocate/free objects (or mul&ple pages) Memory manager asks OS to allocate/free pages (or mul&ple pages) User Program Objects (new, malloc) Allocator(java, libc) Pages (mmap,brk) Operating System

4 Memory Management Ideal memory manager: Fast Raw &me, asympto&c run&me, locality Memory efficient Low fragmenta&on With mul&core & mul&processors: Scalable to mul&ple processors New issues: Secure from asack Reliable in face of errors 4

5 Memory Manager Func=ons Not just malloc/free realloc Change size of object, copying old contents ptr = realloc (ptr, 10); But: realloc(ptr, 0) =? How about: realloc (NULL, 16)? Other fun calloc memalign Needs ability to locate size & object start 5

6 Fragmenta=on Intui&vely, fragmenta&on stems from breaking up heap into unusable spaces More fragmenta&on = worse u&liza&on External fragmenta&on Wasted space outside allocated objects Internal fragmenta&on Wasted space inside an object 6

7 Classical Algorithms First- fit find first chunk of desired size 7

8 Classical Algorithms Best- fit find chunk that fits best Minimizes wasted space 8

9 Classical Algorithms Worst- fit find chunk that fits worst name is a misnomer! keeps large holes around Reclaim space: coalesce free adjacent objects into one big object 9

10 Quick Ac=vity Program asks for: 300,25,25,100 First- fit and best- fit alloca&ons go where? Which ones cannot be fulfilled? What about: 110,54,25,70,50?

11 Implementa=on Techniques Freelists Linked lists of objects in same size class Range of object sizes First- fit, best- fit in this context? Which is faster? 11

12 Implementa=on Techniques Segregated size classes Use free lists, but never coalesce or split Choice of size classes Exact Powers- of- two 12

13 Implementa=on Techniques Big Bag of Pages (BiBOP) Page or pages (mul&ples of 4K) Usually segregated size classes Header contains metadata Locate with bitmasking Limits external fragmenta&on Can be very fast Secret Sauce for project Use free objects to track free objects 13

14 Run=me Analysis Key components Cost of malloc (best, worst, average) Cost of free Cost of size lookup (for realloc & free) 14

15 Space Bounds Fragmenta&on worst- case for op&mal : O(log M/m) M = largest object size m = smallest object size Best- fit = O(M * m)! 15

16 Performance Issues Goal: perform well for typical programs Considera&ons: Internal fragmenta&on External fragmenta&on Headers (metadata) We ll talk about scalability later Reliability, too Canned allocator olen seen as slow 16

17 Custom Memory Alloca=on Programmers replace new/delete Reduce run&me Olen Expand func&onality Some&mes Reduce space rarely Very common Apache, gcc, lcc, STL, database servers Language- level support in C++ Widely recommended Use custom allocators 17

18 Drawbacks of Custom Allocators Avoiding system allocator: More code to maintain & debug Can t use memory debuggers Not modular or robust: Mix memory from custom and general- purpose allocators crash! Increased burden on programmers 18

19 (1) Per- Class Allocators Recycle freed objects from a free list a = new Class1; b = new Class1; c = new Class1; delete a; delete b; delete c; a = new Class1; b = new Class1; c = new Class1; Class1 free list a b c + Fast + Linked list operations + Simple + Identical semantics + C++ language support - Possibly space-inefficient 19

20 (II) Custom Pa9erns Tailor- made to fit alloca&on paserns Example: 197.parser (natural language parser) char[memory_limit] a d b c end_of_array end_of_array a = xalloc(8); b = xalloc(16); c = xalloc(8); xfree(b); xfree(c); d = xalloc(8); + Fast + Pointer-bumping allocation - Brittle - Fixed memory size - Requires stack-like lifetimes 20

21 (III) Regions Separate areas, dele&on only en masse regioncreate(r) regionmalloc(r, sz) r regiondelete(r) + Fast + Pointer- bumping alloca&on + Dele&on of chunks + Convenient + One call frees all memory - Risky - Dangling references - Too much space Increasingly popular custom allocator 21

22 Are custom allocators a win? Generally not worth the trouble use good general- purpose allocator However Some&mes worth it for specialized apps Tells us how to allocate resources from a pool

23 Problems w/unsafe Languages C, C++: pervasive apps, but langs. memory unsafe Numerous opportuni&es for security vulnerabili&es, errors Double free Invalid free Unini&alized reads Dangling pointers Buffer overflows (stack & heap)

24 Soundness for Erroneous Progs Normally: memory errors lead to Consider infinite- heap allocator: All news fresh; ignore delete No dangling pointers, invalid frees, double frees Every object infinitely large No buffer overflows, data overwrites Transparent to correct program Erroneous programs sound

25 Probabilis=c Memory Safety Approximate with M- heaps (e.g., M=2) DieHard: fully- randomized M- heap Increases odds of benign errors Probabilis&c memory safety i.e., P(no error) n Errors independent across heaps E(users with no error) n * users Efficient implementa&on

26 DieHard Derives benefits from three sources Randomized Alloca&on Space- Robustness tradeoff Replica&on

27 Implementa=on Choices Conven&onal, freelist- based heaps Hard to randomize, protect from errors Double frees, heap corrup&on What about bitmaps? [Wilson90] Catastrophic fragmenta&on Each small object likely to occupy one page obj obj obj obj pages

28 Randomized Heap Layout metadata heap Bitmap- based, segregated size classes Bit represents one object of given size i.e., one bit = 2 i+3 bytes, etc. Prevents fragmenta&on

29 Randomized Alloca=on metadata heap malloc(8): compute size class = ceil(log 2 sz) = 3 randomly probe bitmap for zero- bit (free) Fast: run&me O(1) M=2: E[# of probes] 2

30 Randomized Alloca=on metadata heap malloc(8): compute size class = ceil(log 2 sz) = 3 randomly probe bitmap for zero- bit (free) Fast: run&me O(1) M=2: E[# of probes] 2

31 Randomized Dealloca=on metadata heap free(ptr): Ensure object valid aligned to right address Ensure allocated bit set Resets bit Prevents invalid frees, double frees

32 Randomized Dealloca=on metadata heap free(ptr): Ensure object valid aligned to right address Ensure allocated bit set Resets bit Prevents invalid frees, double frees

33 Randomized Dealloca=on metadata heap free(ptr): Ensure object valid aligned to right address Ensure allocated bit set Resets bit Prevents invalid frees, double frees

34 Randomized Heaps & Reliability object size = 2 i My Mozilla: malignant overflow object size = 2 i+4 Objects randomly spread across heap Different run = different heap Errors across heaps independent Your Mozilla: benign overflow

35 DieHard sosware architecture seed 1 replica 1 input seed 2 replica 2 output broadcast vote seed 3 replica 3 execute replicas (separate processes) Replica&on- based fault- tolerance Requires randomiza&on: errors independent

36 DieHard Results Empirical results Run&me overhead Error avoidance Injected faults & actual applica&ons Analy&cal results (if &me, pictures!) Buffer overflows Unini&alized reads Dangling pointer errors (the best)

37 Empirical Results: Run=me

38 Error Avoidance Injected faults: Dangling pointers 10 alloca&ons) glibc: crashes; DieHard: 9/10 correct Overflows 4 bytes over) glibc: crashes 9/10, inf loop; DieHard: 10/10 correct Real faults: Avoids Squid web cache overflow Crashes Boehm- Demers- Weiser(BDW) Collector & glibc Avoids dangling pointer error in Mozilla DoS in glibc & Windows

39 The End 39

40 Analy&cal Results: Buffer Overflows Model overflow as write of live data Heap half full (max occupancy)

41 Analy&cal Results: Buffer Overflows Model overflow as write of live data Heap half full (max occupancy)

42 Analy&cal Results: Buffer Overflows Model overflow: random write of live data Heap half full (max occupancy)

43 Analy=cal Results: Overflows Replicas: Increase odds of avoiding overflow in at least one replica replicas

44 Analy=cal Results: Overflows Replicas: Increase odds of avoiding overflow in at least one replica replicas

45 Analy=cal Results: Overflows Replicas: Increase odds of avoiding overflow in at least one replica replicas P(Overflow in all replicas) = (½)3 = 1/8 P(No overflow in > 1 replica) = 1- (½)3 = 7/8

46 Analy&cal Results: Buffer Overflows F = free space H = heap size N = # objects worth of overflow k = replicas Overflow one object

47 Custom Allocators Are Faster Runtime - Custom Allocator Benchmarks Custom Win32 Normalized Runtime parser non-regions boxed-sim c-breeze 175.vpr 176.gcc regions apache lcc mudlle As good as and some&mes much faster than Win32 47

48 Not So Fast Runtime - Custom Allocator Benchmarks Custom Win32 DLmalloc Normalized Runtime parser non-regions boxed-sim c-breeze 175.vpr 176.gcc regions apache lcc mudlle DLmalloc: as fast or faster for most benchmarks 48

49 Lea Allocator (Dlmalloc 2.7.0) Mature general- purpose allocator Op&mized for common alloca&on paserns Per- size quicklists per- class alloca&on Deferred coalescing combining adjacent free objects Highly- op&mized fastpath Space- efficient 49

50 Space Consump=on: Mixed Space - Custom Allocator Benchmarks Custom DLmalloc Normalized Space non-regions regions 197.parser boxed-sim c-breeze 175.vpr 176.gcc apache lcc mudlle 50

51 Custom Allocators? Generally not worth the trouble: use good general- purpose allocator Avoids risky solware engineering errors 51