Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Memory Attributes - Lecture Slides | CMSC 330, Study notes of Programming Languages

University of MarylandProgramming Languages

Material Type: Notes; Class: ORGNZTN PROGM LANG; Subject: Computer Science; University: University of Maryland; Term: Fall 2007;

Typology: Study notes

Pre 2010

Uploaded on 02/13/2009

koofers-user-akh
koofers-user-akh 🇺🇸

9 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
CMSC 330: Organization of
Programming Languages
Garbage Collection
CMSC 330 2
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 memory
– Programmer allocated memory
– Persistent memory
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

Download Memory Attributes - Lecture Slides | CMSC 330 and more Study notes Programming Languages in PDF only on Docsity!

CMSC 330: Organization of

Programming Languages

Garbage Collection

CMSC 330 2

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 memory - Programmer allocated memory - Persistent memory

CMSC 330 3

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

CMSC 330 4

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)

CMSC 330 7

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

CMSC 330 8

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

CMSC 330 9

Memory Management in OCaml

• Local variables live on the stack

• Tuples, closures, and constructed types live on

the heap

  • let x = (3, 4) (* heap-allocated *)
  • let f x y = x + y in f 3 (* 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 memory

CMSC 330 10

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

CMSC 330 13

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

CMSC 330 14

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

– 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

CMSC 330 15

Reachability

• 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 anyway

CMSC 330 16

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

CMSC 330 19

Reference Counting Example

stack 1

CMSC 330 20

Reference Counting Example

stack 1

CMSC 330 21

Reference Counting Example

stack 1

CMSC 330 22

Reference Counting Example

stack 1 2

CMSC 330 25

Tradeoffs

  • Advantage: incremental technique
    • Generally small, constant amount of work per memory write
    • With more effort, can even bound running time
  • Disadvantages:
    • Cascading decrements can be expensive
    • Can’t collect cycles, since counts never go to 0
    • Also requires extra storage for reference counts

CMSC 330 26

Mark and Sweep GC

• Idea: Only objects reachable from stack could

possibly be live

  • Every so often, stop the world and do GC:
    • Mark all objects on stack as live
    • Until no more reachable objects,
      • Mark object reachable from live object as live
    • Deallocate any non-reachable objects

• This is a tracing garbage collector

• Does not handle fragmentation problem

CMSC 330 27

Mark and Sweep Example

stack

CMSC 330 28

Mark and Sweep Example

stack

CMSC 330 31

Mark and Sweep Example

stack

CMSC 330 32

Mark and Sweep Example

stack

CMSC 330 33

Mark and Sweep Example

stack

CMSC 330 34

Tradeoffs with Mark and Sweep

  • Pros:
    • No problem with cycles
    • Memory writes have no cost
  • Cons:
    • Fragmentation
      • Available space broken up into many small pieces
        • Thus many mark-and-sweep systems may also have a compaction phase (like defragmenting your disk)
    • Cost proportional to heap size
      • Sweep phase needs to traverse whole heap – it touches dead memory to put it back on to the free list
    • Not appropriate for real-time applications
      • You wouldn’t like your auto’s braking system to stop working for a GC while you are trying to stop at a busy intersection

CMSC 330 37

Stop and Copy Example

stack



CMSC 330 38

Stop and Copy Example

stack



CMSC 330 39

Stop and Copy Example

stack



CMSC 330 40

Stop and Copy Tradeoffs

• Pros:

– Only touches live data

– No fragmentation; automatically compacts

• Will probably increase locality

• Cons:

– Requires twice the memory space

– Like mark and sweep, need to “stop the

world”

• Program must stop running to let garbage

collector move around data in the heap