Memory and Garbage Collection - Notes | CMSC 330, Study notes of Programming Languages

Download Memory and Garbage Collection - Notes | CMSC 330 and more Study notes Programming Languages in PDF only on Docsity!

CMSC 330: Organization of

Programming Languages

Memory and Garbage Collection

Memory 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 (or stack) memory - (^) Allocated (or heap) memory - (^) Persistent (or disk) memory

Memory 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)

Memory 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 programmer

Ways 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 C
    • (^) allows you to allocate memory basically as you normally would, without explicitly deallocating memory that is no longer useful. The collector automatically recycles memory when it determines that it can no longer be otherwise accessed.

Memory 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 memory

Memory 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 management

Another Memory Problem: Fragmentation

allocate(a); allocate(x); allocate(y); free(a); allocate(z); free(y); allocate(b);  No contiguous space for b

Garbage 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 impossible

Many 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
• (^) Err on the conservative side:
  • (^) OK if we decide something is live when it’s not
  • (^) But we’d better not deallocate an object that will be used later on

Roots

• (^) 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 chasing and garbage collection

Reference Counting (Smart Pointers)

• (^) 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 problem

Reference Counting Example

stack 1 1 2 1 1

Reference Counting Example

stack 1 1 2 1 1