1 / 33

Memory Management

Memory Management. Garbage Collection. Modes of Object Management. Static * An entity may become attached to at most one run-time object during the entire execution. E.g., FORTRAN variables. + Simple and Efficient. Precludes recursion. Precludes dynamic data structures.

samson
Download Presentation

Memory Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Memory Management Garbage Collection L9GC

  2. Modes of Object Management • Static * An entity may become attached to at most one run-time object during the entire execution. • E.g., FORTRAN variables. + Simple and Efficient. • Precludes recursion. • Precludes dynamic data structures. • Note, FORTRAN 90 supports recursion and pointers. L9GC

  3. Stack-based * An entity may at run-time become attached to several objects in succession, and the allocation and deallocation of these objects is in last-in first-out discipline. • E.g., Pascal, C/C++, Java, etc. + Well-matched with block-structuring. + Allocation and Deallocation automatic. + Supports recursion. + Supports Ada “unconstrained” array types, etc. • Does not support flexible data structures. L9GC

  4. Heap-based * Objects are created dynamically through explicit requests. • E.g., C++, LISP, Java/C#, etc. + Enables construction of complex dynamic data structures (with “unpredictable” lifetimes). • Requires techniques for memory reclamation. • Objects may become unreachable as a result of an assignment or a method-return. • Even systems with large virtual memory can thrash if memory is not recycled. L9GC

  5. L9GC

  6. Programmer Controlled Deallocation • Using language primitives • E.g., Pascal’s dispose, C’s free, C++’s delete, C++ destructors, etc. • Reliability issue • Dangling reference problem (“premature freeing”) • Memory Leakage (“incomplete recycling”) • Ease of software development issue • Component-level approach L9GC

  7. Automatic Memory Management Language implementation techniques (run-time system) • Reference counting • Restricted to acyclic data structures. • Garbage collection + Applicable to general dynamic data structures. • Unsuitable in certain areas such as hard real-time systems. L9GC

  8. Reference counting • Keep count of number of references to each object. • Update the count in response to operations. • initialize : create/clone • increment : assignment, method call • decrement : assignment, method return. L9GC

  9. (cont) • Limitations • Space/time overhead to maintain count. • Memory leakage when cycles in data. • Advantage • Incremental algorithm • Applications • UNIX File System - Symbolic Links • Java RMI, Strings, COM/DCOM • Pure Functional Languages • Scripting Languages : Python, PERL, etc L9GC

  10. Garbage Collection • Detecting and reclaiming unreachable objects automatically. • Soundness / Safety • Every collected object is unreachable. • Completeness • Every unreachable object is eventually collected. L9GC

  11. Reachability is an Approximation • Consider the program: x ¬ new A; y ¬ new B; x ¬ y; if alwaysTrue() then x ¬ new A else x.foo() fi • Afterx ¬ y (assuming y becomes dead there) • the initial object A is not reachable anymore • the object B is reachable (through x) • thus B is not garbage and is not collected • but object B is never going to be used L9GC

  12. Soundness issue : C++ Problem void main(void){ Point *aptr = new Point(); // casting an object reference to an int int i = (int) aptr; // normal access to an object and its fields aptr->print(); aptr->printxy(); // freeing an object and nulling a reference to it delete(aptr); aptr = NULL; aptr->print(); // segmentation fault only when the object fields are accessed // aptr->printxy(); // casting the int back to object reference aptr = (Point*) i; // object resurrected !! aptr->print(); aptr->printxy(); } L9GC

  13. Mark and Sweep Algorithm • Garbage Detection • Depth-first search to mark live data cells (cells in heap reachable from variables on run-time stack). • Garbage Reclamation • Sweep through entire memory, putting unmarked nodes on freelist. Sweep also unmarks the marked nodes. L9GC

  14. Mark phase : Using an explicit stack function DFS(r) ifr is a reference and object r not marked then{ mark object r; t <- 1; stack[t] <- r; while (t > 0) { p <- stack[t--]; foreach field p.fi do { ifp.fi is a reference and object p.fi not marked then{mark object p.fi; stack[++t] <- p.fi }}}} L9GC

  15. Sweep phase p <- first address in heap; while (p < last address in heap) { if marked object p thenunmark object p else{ let f be the first field in object p; p.f <- freelist; freelist <- p; } p <- p + (size of object p) } L9GC

  16. A root B 0 C 0 D 0 E 0 F 0 0 free After mark: A root B 0 C 1 D 0 E 0 F 1 1 free After sweep: A root B 0 C 0 D 0 E 0 F 0 0 free Mark and Sweep Example L9GC

  17. Problems • Memory Fragmentation. • Work proportional to size of heap. • Potential lack of locality of reference for newly allocated objects (fragmentation). • Solution • Compaction • Contiguous live objects, contiguous free space L9GC

  18. Copying Collection • Divide heap into two “semispaces”. • Allocate from one space (fromspace) till full. • Copy live data into other space (tospace). • Switch roles of the spaces. • Requires fixing pointers to moved data (forwarding). • Eliminates fragmentation. • DFS improves locality, while BFS does not require any extra storage. L9GC

  19. heap pointer root After collection: new space A C F free Stop and Copy GC: Example Before collection: A root B C D E F new space L9GC

  20. Implementation of Stop and Copy • We find and copy all the reachable objects into the new space, and fix ALL pointers pointing to moved objects! • As we copy an object, we store in the old copy a forwarding pointer to the new copy • when we later reach an object with a forwarding pointer, we know it was already copied L9GC

  21. Implementation of Stop and Copy (Cont.) • We still have the issue of how to implement the traversal without using extra space • The following trick solves the problem: • partition the new space in three contiguous regions start scan alloc copied copied and scanned empty copied objects whose pointer fields were NOT followed copied objects whose pointer fields were followed L9GC

  22. Stop and Copy. Example (1) • Before garbage collection A root B C D E F new space L9GC

  23. Stop and Copy. Example (2) • Step 1: Copy the objects pointed by roots and set forwarding pointers alloc scan A E A root B C D F L9GC

  24. Stop and Copy. Example (3) • Step 2: Follow the pointer in the next unscanned object (A) • copy the pointed objects (just C in this case) • fix the pointer (to C) in A • set forwarding pointer in C alloc scan C A E A root B C D F L9GC

  25. Stop and Copy. Example (4) • Follow the pointer in the next unscanned object (C) • copy the pointed objects (F in this case) alloc scan C F A E A root B C D F L9GC

  26. Stop and Copy. Example (5) • Follow the pointer in the next unscanned object (F) • the pointed object (A) was already copied. Set the pointer same as the forwarding pointer alloc scan C F A E A root B C D F L9GC

  27. Stop and Copy. Example (6) • Since scan caught up with alloc we are done • Swap the role of the spaces and resume the program alloc scan root new space C F A L9GC

  28. Generational Collectors • Observation • Most objects short-lived, small percentage long lived. • 80% to 98% new objects die very quickly. • An object that has survived several collections has a bigger chance to become a long-lived one. • It is inefficient to copy long-lived objects over and over again. • Strategy • Partition objects based on age, collecting areas containing “younger” objects more frequently than “older” ones. • Advantages • Less effort on each collection (reduced pause time). • Avoids unnecessary copying of long-lived objects (efficiency). • Improves locality (temporal and spatial locality correlated) L9GC

  29. Generational Garbage Collection Segregate objects into multiple areas (2 ~ 7) by age, and collect older areas less often than the younger ones. L9GC

  30. Practical Issues • Unpredictability • Major concern in critical applications. + Support collect_on, collect_off, collect_now. • Efficiency • Generation scavenging; Clustering • Incrementality • Separate GC thread running concurrently. • Finalization • Recycling non-memory resources. • External Calls • Interfacing with other languages L9GC

  31. Memory Leakage in Java (Unintended References) public class Stack { private static final int MAXLEN = 10; private Object stk[] = new Object[MAXLEN]; private int stkp = -1; public void push(Object p) { stk[++stkp] = p; } public Object pop() { return stk[stkp--]; } } L9GC

  32. In order to ensure that the popped object is promptly available to the garbage collector, it must be made explicitly “unreachable” by setting the object reference in stk[top] to null. public Object pop(){ Object p = stk[stkp]; stk[stkp--] = null; return p; } L9GC

  33. Other Java Details • Class representations stay in memory as long as the corresponding class loader is present. This is because the contents of the class (static) variables may be needed later. Unintended references from class variables to instances can cause memory leakage. • See Reference Objects and java.lang.ref package in Java 2 for GC related issues. L9GC

More Related