DOC PREVIEW
UMD CMSC 330 - Garbage Collection

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CMSC 330: Organization of Programming LanguagesGarbage CollectionCMSC 330 2Memory attributes• Memory to store data in programming languages has several attributes:– Persistence (or lifetime) – How long the memory exists– Allocation – When the memory is available for use– Recovery – When the system recovers the memory for reuse• Most programming languages are concerned with some subset of the following 4 memory classes:–Fixed(or static) memory– Automatic memory– Programmer allocated memory– Persistent memoryCMSC 330 3Memory classes• Static memory – Usually a fixed address in memory– Persistence – Lifetime of execution of program– Allocation – By compiler for entire execution– Recovery – By system when program terminates• Automatic memory – Usually on a stack– Persistence – Lifetime of method using that data– Allocation – When method is invoked– Recovery – When method terminatesCMSC 330 4Memory classes• Allocated memory – Usually memory on a heap– Persistence – As long as memory is needed– Allocation – Explicitly by programmer– Recovery – Either by programmer or automatically (when possible and depends upon language)• Persistent memory – Usually the file system– Persistence – Multiple execution of a program (e.g., files or databases)– Allocation – By program or user, often outside of program execution– Recovery – When data no longer needed– This form of memory usually outside of programming language course and part of database area (e.g., CMSC 424)CMSC 330 5Memory Management in C• Local variables live on the stack– Allocated at function invocation time– Deallocated when function returns– Storage space reused after function returns• Space on the heap allocated with malloc()– Must be explicitly freed with free()– This is called explicit or manual memory management• Deletions must be done by the userCMSC 330 6Memory Management Mistakes• May forget to free memory (memory leak){ int *x = (int *) malloc(sizeof(int)); }• May retain ptr to freed memory (dangling pointer){ int *x = ...malloc();free(x);*x=5;/*oops!*/}• May try to free something twice{ int *x = ...malloc(); free(x); free(x); }• This may corrupt the memory management data structures– E.g., the memory allocator maintains a free list of space on the heap that’s available2CMSC 330 7Ways to Avoid Mistakes• Don’t allocate memory on the heap– Often impractical– Leads to confusing code• Never free memory– OS will reclaim process’s memory anyway at exit– Memory is cheap; who cares about a little leak?– LISP model – System halts program and reclaims unused memory when there is no more available• Use a garbage collector– E.g., conservative Boehm-Weiser collector for CCMSC 330 8Memory Management in Ruby• Local variables live on the stack– Storage reclaimed when method returns• Objects live on the heap– Created with calls to Class.new• Objects never explicitly freed– Ruby uses automatic memory management• Uses a garbage collector to reclaim memoryCMSC 330 9Memory Management in OCaml• Local variables live on the stack• Tuples, closures, and constructed types live on the heap– let x = (3, 4) (* heap-allocated *)– letfxy=x+yinf3(* result heap-allocated *)– type ‘a t = None | Some of ‘a– None (* not on the heap–just a primitive *)– Some 37 (* heap-allocated *)• Garbage collection reclaims memoryCMSC 330 10Memory Management in Java• Local variables live on the stack– Allocated at method invocation time– Deallocated when method returns• Other data lives on the heap– Memory is allocated with new– But never explicitly deallocated• Java uses automatic memory managementCMSC 330 11Memory Problem: Fragmentationallocate(a);allocate(x);allocate(y);free(a);allocate(z);free(y);allocate(b);⇒ No contiguous space for bCMSC 330 12Garbage collection goal• Process to reclaim memory. (Also solve Fragmentation problem.)• Algorithm: You can do garbage collection and memory compaction if you know where every pointer is in a program. If you move the allocated storage, simply change the pointer to it.• This is true in LISP, OCAML, Java, Prolog • Not true in C, C++, Pascal, Ada3CMSC 330 13Garbage Collection (GC)• At any point during execution, can divide the objects in the heap into two classes:– Live objects will be used later– Dead objects will never be used again• They are garbage• Idea: Can reuse memory from dead objects• Goals: Reduce memory leaks, and make dangling pointers impossibleCMSC 330 14Many GC Techniques• In most languages we can’t know for sure which objects are really live or dead– Undecidable, like solving the halting problem• Thus we need to make an approximation– OK if we decide something is live when it’s not– But we’d better not deallocate an object that will be used later onCMSC 330 15Reachability• An object is reachable if it can be accessed by chasing pointers from live data• Safe policy: delete unreachable objects– An unreachable object can never be accessed again by the program• The object is definitely garbage– A reachable object may be accessed in the future • The object could be garbage but will be retained anywayCMSC 330 16Roots• At a given program point, we define liveness as being data reachable from the root set:– Global variables– Local variables of all live method activations (i.e., the stack)• At the machine level, we also consider the register set (usually stores local or global variables)• Next: techniques for pointer chasingCMSC 330 17Reference Counting• Old technique (1960)• Each object has count of number of pointers to it from other objects and from the stack– When count reaches 0, object can be deallocated• Counts tracked by either compiler or manually• To find pointers, need to know layout of objects– In particular, need to distinguish pointers from ints• Method works mostly for reclaiming memory; doesn’t handle fragmentation problemCMSC 330 18Reference Counting Examplestack1124CMSC 330 19Reference Counting Examplestack11211CMSC 330 20Reference Counting Examplestack11211CMSC 330 21Reference Counting Examplestack112110CMSC 330 22Reference Counting Examplestack1211CMSC 330 23Reference Counting Examplestack12110CMSC 330 24Reference Counting Examplestack15CMSC 330 25Tradeoffs• Advantage: incremental technique– Generally small, constant amount of work


View Full Document

UMD CMSC 330 - Garbage Collection

Documents in this Course
Exam #1

Exam #1

6 pages

Quiz #1

Quiz #1

2 pages

Midterm 2

Midterm 2

12 pages

Exam #2

Exam #2

7 pages

Ocaml

Ocaml

7 pages

Parsing

Parsing

38 pages

Threads

Threads

12 pages

Ruby

Ruby

7 pages

Quiz #3

Quiz #3

2 pages

Threads

Threads

7 pages

Quiz #4

Quiz #4

2 pages

Exam #2

Exam #2

6 pages

Exam #1

Exam #1

6 pages

Threads

Threads

34 pages

Quiz #4

Quiz #4

2 pages

Threads

Threads

26 pages

Exam #2

Exam #2

9 pages

Exam #2

Exam #2

6 pages

Load more
Download Garbage Collection
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Garbage Collection and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Garbage Collection 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?