Automatic Memory Management

Similar documents
One-Slide Summary. Lecture Outine. Automatic Memory Management #1. Why Automatic Memory Management? Garbage Collection.

Lecture Outine. Why Automatic Memory Management? Garbage Collection. Automatic Memory Management. Three Techniques. Lecture 18

ACM Trivia Bowl. Thursday April 3 rd (two days from now) 7pm OLS 001 Snacks and drinks provided All are welcome! I will be there.

Automatic Memory Management

Automatic Memory Management

Run-Time Environments/Garbage Collection

Lecture 13: Garbage Collection

Runtime. The optimized program is ready to run What sorts of facilities are available at runtime

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages. Memory Management and Garbage Collection

Lecture 15 Garbage Collection

Lecture 15 Advanced Garbage Collection

Garbage Collection. Akim D le, Etienne Renault, Roland Levillain. May 15, CCMP2 Garbage Collection May 15, / 35

Deallocation Mechanisms. User-controlled Deallocation. Automatic Garbage Collection

Heap Management. Heap Allocation

Automatic Garbage Collection

CSE P 501 Compilers. Memory Management and Garbage Collec<on Hal Perkins Winter UW CSE P 501 Winter 2016 W-1

Garbage Collection. Steven R. Bagley

Run-time Environments -Part 3

Garbage Collection Algorithms. Ganesh Bikshandi

CS61C : Machine Structures

Implementation Garbage Collection

Sustainable Memory Use Allocation & (Implicit) Deallocation (mostly in Java)

G Programming Languages - Fall 2012

Acknowledgements These slides are based on Kathryn McKinley s slides on garbage collection as well as E Christopher Lewis s slides

6.172 Performance Engineering of Software Systems Spring Lecture 9. P after. Figure 1: A diagram of the stack (Image by MIT OpenCourseWare.

Programming Language Implementation

Memory Management. Memory Management... Memory Management... Interface to Dynamic allocation

Exploiting the Behavior of Generational Garbage Collector

CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 11

Robust Memory Management Schemes

Compilers. 8. Run-time Support. Laszlo Böszörmenyi Compilers Run-time - 1

CS61C : Machine Structures

Garbage Collection. Hwansoo Han

Garbage Collection (1)

Lecture Notes on Garbage Collection

Lecture 7 More Memory Management Slab Allocator. Slab Allocator

Garbage Collection. CS 351: Systems Programming Michael Saelee

Compiler Construction

Algorithms for Dynamic Memory Management (236780) Lecture 1

Garbage Collection. Weiyuan Li

Memory Allocation. Static Allocation. Dynamic Allocation. Dynamic Storage Allocation. CS 414: Operating Systems Spring 2008

CS61C : Machine Structures

Algorithms for Dynamic Memory Management (236780) Lecture 4. Lecturer: Erez Petrank

CS61C : Machine Structures

CS2210: Compiler Construction. Runtime Environment

Dynamic Storage Allocation

CS577 Modern Language Processors. Spring 2018 Lecture Garbage Collection

Compiler Construction

CS 345. Garbage Collection. Vitaly Shmatikov. slide 1

CS S-11 Memory Management 1

Lecture Notes on Advanced Garbage Collection

Dynamic Memory Management! Goals of this Lecture!

Lecture 13: Complex Types and Garbage Collection

CS 4120 Lecture 37 Memory Management 28 November 2011 Lecturer: Andrew Myers

Manual Allocation. CS 1622: Garbage Collection. Example 1. Memory Leaks. Example 3. Example 2 11/26/2012. Jonathan Misurda

A.Arpaci-Dusseau. Mapping from logical address space to physical address space. CS 537:Operating Systems lecture12.fm.2

Dynamic Memory Management

Design Issues. Subroutines and Control Abstraction. Subroutines and Control Abstraction. CSC 4101: Programming Languages 1. Textbook, Chapter 8

High-Level Language VMs

(notes modified from Noah Snavely, Spring 2009) Memory allocation

Book keeping. Will post HW5 tonight. OK to work in pairs. Midterm review next Wednesday

Lecture 7: Binding Time and Storage

Garbage Collection Techniques

Mark-Sweep and Mark-Compact GC

CS 241 Honors Memory

Performance of Non-Moving Garbage Collectors. Hans-J. Boehm HP Labs

CS2210: Compiler Construction. Runtime Environment

Memory Allocation III

Motivation for Dynamic Memory. Dynamic Memory Allocation. Stack Organization. Stack Discussion. Questions answered in this lecture:

Habanero Extreme Scale Software Research Project

CS Computer Systems. Lecture 8: Free Memory Management

Memory Management. Chapter Fourteen Modern Programming Languages, 2nd ed. 1

Run-time Environments - 3

Memory. don t forget to take out the

Lecture Notes on Garbage Collection

Dynamic Memory Management

Dynamic Memory Allocation: Advanced Concepts

Verifying a Concurrent Garbage Collector using a Rely-Guarantee Methodology

Dynamic Memory Allocation II October 22, 2008

CSCI-1200 Data Structures Fall 2011 Lecture 24 Garbage Collection & Smart Pointers

Java & Coherence Simon Cook - Sales Consultant, FMW for Financial Services

Memory Allocation III

Opera&ng Systems CMPSCI 377 Garbage Collec&on. Emery Berger and Mark Corner University of Massachuse9s Amherst

Shenandoah An ultra-low pause time Garbage Collector for OpenJDK. Christine H. Flood Roman Kennke

Memory Management. Didactic Module 14 Programming Languages - EEL670 1

06 A Low-Level Virtual Machine

CS61C : Machine Structures

Heap Compression for Memory-Constrained Java

CS558 Programming Languages

CS842: Automatic Memory Management and Garbage Collection. Mark and sweep

Process s Address Space. Dynamic Memory. Backing the Heap. Dynamic memory allocation 3/29/2013. When a process starts the heap is empty

Run-time Environments. Lecture 13. Prof. Alex Aiken Original Slides (Modified by Prof. Vijay Ganesh) Lecture 13

HOT-Compilation: Garbage Collection

Shenandoah: An ultra-low pause time garbage collector for OpenJDK. Christine Flood Roman Kennke Principal Software Engineers Red Hat

Binding and Storage. COMP 524: Programming Language Concepts Björn B. Brandenburg. The University of North Carolina at Chapel Hill

A new Mono GC. Paolo Molaro October 25, 2006

CS558 Programming Languages

Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

Transcription:

Automatic Memory Management

Why Automatic Memory Management? Storage management is still a hard problem in modern programming

Why Automatic Memory Management? Storage management is still a hard problem in modern programming C and C++ programs have many storage bugs forgetting to free unused memory dereferencing a dangling pointer overwriting parts of a data structure by accident and so on...

Why Automatic Memory Management? Storage management is still a hard problem in modern programming C and C++ programs have many storage bugs forgetting to free unused memory dereferencing a dangling pointer overwriting parts of a data structure by accident and so on... Storage bugs are hard to find a bug can lead to a visible effect far away in time and program text from the source

Automatic Memory Management This is an old problem: Studied since the 1950s for LISP

Automatic Memory Management This is an old problem: Studied since the 1950s for LISP There are several well-known techniques for performing completely automatic memory management

Automatic Memory Management This is an old problem: Studied since the 1950s for LISP There are several well-known techniques for performing completely automatic memory management Until recently they were unpopular outside the Lisp family of languages Became mainstream with the popularity of Java

The Basic Idea When an object that takes memory space is created, unused space is automatically allocated In Cool, new objects are created by new X

The Basic Idea When an object that takes memory space is created, unused space is automatically allocated In Cool, new objects are created by new X After a while there is no more unused space

The Basic Idea When an object that takes memory space is created, unused space is automatically allocated In Cool, new objects are created by new X After a while there is no more unused space Some space is occupied by objects that will never be used again

The Basic Idea When an object that takes memory space is created, unused space is automatically allocated In Cool, new objects are created by new X After a while there is no more unused space Some space is occupied by objects that will never be used again This space can be freed to be reused later

The Basic Idea (Cont.) How can we tell whether an object will never be used again? In general it is impossible to tell We will have to use a heuristic to find many (not all) objects that will never be used again

The Basic Idea (Cont.) How can we tell whether an object will never be used again? In general it is impossible to tell We will have to use a heuristic to find many (not all) objects that will never be used again Observation: a program can use only the objects that it can find: let x : A new A in { x y;... } x A y

The Basic Idea (Cont.) How can we tell whether an object will never be used again? In general it is impossible to tell We will have to use a heuristic to find many (not all) objects that will never be used again Observation: a program can use only the objects that it can find: let x : A new A in { x y;... } After x y there is no way to access the newly allocated object x A y

Garbage An object x is reachable if and only if: A register contains a pointer to x, or Another reachable object y contains a pointer to x R R

Garbage An object x is reachable if and only if: A register contains a pointer to x, or Another reachable object y contains a pointer to x You can find all reachable objects by starting from registers and following all the pointers R R

Garbage An object x is reachable if and only if: A register contains a pointer to x, or Another reachable object y contains a pointer to x You can find all reachable objects by starting from registers and following all the pointers An unreachable object can never by referred by the program These objects are called garbage R R

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 x y A B

Reachability is an Approximation Consider the program: x new A; y new B Time for GC x y; if alwaystrue() then x new A else x.foo() fi x y A B

Reachability is an Approximation Consider the program: x new A; y new B Time for GC x y; if alwaystrue() then x new A else x.foo() fi After x y (assuming y becomes dead there) The 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 x y A B

Reachability is an Approximation Consider the program: x new A; y new B Time for GC x y; if alwaystrue() then x new A else x.foo() fi After x y (assuming y becomes dead there) The 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 Reachability is an approximation!! x y A B

Tracing ReachableValues in Coolc In coolc, the only register is the accumulator it points to an object and this object may point to other objects, etc.

Tracing ReachableValues in Coolc In coolc, the only register is the accumulator it points to an object and this object may point to other objects, etc. The stack is more complex each stack frame contains pointers e.g., method parameters each stack frame also contains non-pointers e.g., return address if we know the layout of the frame we can find the pointers in it e.g., activation record

A Simple Example acc A B C D E SP Frame 1 Frame 2 In Coolc we start tracing from acc and stack they are called the roots (registers)

A Simple Example acc A B C D E SP Frame 1 Frame 2 In Coolc we start tracing from acc and stack they are called the roots (registers) B and D are not reachable from acc or the stack Thus we can reuse their storage

Elements of Garbage Collection Every garbage collection scheme has the following steps 1. Allocate space as needed for new objects 2. When space runs out: a) Compute what objects might be used again (generally by tracing objects reachable from a set of root registers) b) Free the space used by objects not found in (a)

Elements of Garbage Collection Every garbage collection scheme has the following steps 1. Allocate space as needed for new objects 2. When space runs out: a) Compute what objects might be used again (generally by tracing objects reachable from a set of root registers) b) Free the space used by objects not found in (a) Some strategies perform garbage collection before the space actually runs out

Mark and Sweep [McCarthy 1960] When memory runs out, GC executes two phases the mark phase: traces reachable objects the sweep phase: collects garbage objects

Mark and Sweep [McCarthy 1960] When memory runs out, GC executes two phases the mark phase: traces reachable objects the sweep phase: collects garbage objects Every object has an extra bit: the mark bit reserved for memory management initially the mark bit is 0 set to 1 for the reachable objects in the mark phase

The Mark Phase let todo = { all roots } while todo do pick v todo todo todo - { v } if mark(v) = 0 then (* v is unmarked yet *) mark(v) 1 let v 1,...,v n be the pointers contained in v todo todo {v 1,...,v n } fi od

The Sweep Phase The sweep phase scans the heap looking for objects with mark bit 0 these objects have not been visited in the mark phase they are garbage

The Sweep Phase The sweep phase scans the heap looking for objects with mark bit 0 these objects have not been visited in the mark phase they are garbage Any such object is added to the free list The objects with a mark bit 1 have their mark bit reset to 0

The Sweep Phase (Cont.) /* sizeof(p) is the size of block starting at p */ p bottom of heap while p < top of heap do if mark(p) = 1 then mark(p) 0 else add block p...(p+sizeof(p)-1) to freelist fi p p + sizeof(p) od

Mark and Sweep Example root A 0 B 0 C 0 D 0 E 0 F 0 free

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

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

Mark and Sweep: Details While conceptually simple, this algorithm has a number of tricky details this is typical of GC algorithms

Mark and Sweep: Details While conceptually simple, this algorithm has a number of tricky details this is typical of GC algorithms A serious problem with the mark phase it is invoked when we are out of space yet it needs space to construct the todo list the size of the todo list is unbounded so we cannot reserve space for it a priori

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 0 0 0 0 0

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 0 0 0 0 0

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 0 0 1 0 0

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 0 1 1 0 0

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 1 1 1 0 0

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 1 1 1 0 1

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 1 1 1 1 1

Mark and Sweep: Details The todo list is used as an auxiliary data structure to perform the reachability analysis There is a trick that allows the auxiliary data to be stored in the objects themselves pointer reversal: when a pointer is followed it is reversed to point to its parent R 1 1 1 1 1

Mark and Sweep: Evaluation Space for a new object is allocated from the free list a block large enough is picked an area of the necessary size is allocated from it the left-over is put back in the free list

Mark and Sweep: Evaluation Space for a new object is allocated from the free list a block large enough is picked an area of the necessary size is allocated from it the left-over is put back in the free list Mark and sweep can fragment the memory

Mark and Sweep: Evaluation Space for a new object is allocated from the free list a block large enough is picked an area of the necessary size is allocated from it the left-over is put back in the free list Mark and sweep can fragment the memory Advantage: objects are not moved during GC no need to update the pointers to objects works for languages like C and C++

Another Technique: Stop and Copy Memory is organized into two areas Old space: used for allocation New space: used as a reserve for GC heap pointer old space new space

Another Technique: Stop and Copy Memory is organized into two areas Old space: used for allocation New space: used as a reserve for GC heap pointer old space new space The heap pointer points to the next free word in the old space Allocation just advances the heap pointer

Stop and Copy Garbage Collection GC starts when the old space is full

Stop and Copy Garbage Collection GC starts when the old space is full Copies all reachable objects from old space into new space garbage is left behind after the copy phase the new space uses less space than the old one before the collection

Stop and Copy Garbage Collection GC starts when the old space is full Copies all reachable objects from old space into new space garbage is left behind after the copy phase the new space uses less space than the old one before the collection After the copy the roles of the old and new spaces are reversed and the program resumes

Stop and Copy Garbage Collection: Example Before collection: root A B C D E F new space

Stop and Copy Garbage Collection: Example Before collection: root A B C D E F new space

Stop and Copy Garbage Collection: Example Before collection: root A B C D E F new space After collection: root heap pointer new space A C F free

Implementation of Stop and Copy We need to find all the reachable objects, as for mark and sweep

Implementation of Stop and Copy We need to find all the reachable objects, as for mark and sweep As we find a reachable object we copy it into the new space And we have to fix ALL pointers pointing to it! How many times of copying of A? root A B C D E F new space

Implementation of Stop and Copy We need to find all the reachable objects, as for mark and sweep As we find a reachable object we copy it into the new space And we have to fix ALL pointers pointing to it! How many times of copying of A? 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

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 and scanned copied objects whose pointer fields were followed and fixed copied copied objects whose pointer fields were NOT followed empty

Stop and Copy: Example (1) Before garbage collection start scan alloc root A B C D E F new space

Stop and Copy: Example (3) Step 1: Copy the objects pointed by roots and set forwarding pointers (dotted arrow) start scan alloc root A B C D E F A

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 in A set forwarding pointer scan start alloc root A B C D E F A C

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

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 forwading pointer start scan alloc root A B C D E F A C F

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

The Stop and Copy Algorithm while scan <> alloc do let O be the object at scan pointer for each pointer p contained in O do find O that p points to if O is without a forwarding pointer copy O to new space (update alloc pointer) set a word of old O to point to the new copy change p to point to the new copy of O else set p in O equal to the forwarding pointer fi end for increment scan pointer to the next object od

Stop and Copy: Details As with mark and sweep, we must be able to tell how large is an object when we scan it And we must also know where are the pointers inside the object

Stop and Copy: Details As with mark and sweep, we must be able to tell how large is an object when we scan it And we must also know where are the pointers inside the object We must also copy any objects pointed to by the stack and update pointers in the stack This can be an expensive operation

Stop and Copy: Evaluation Stop and copy is generally believed to be the fastest GC technique

Stop and Copy: Evaluation Stop and copy is generally believed to be the fastest GC technique Allocation is very cheap Just increment the heap pointer

Stop and Copy: Evaluation Stop and copy is generally believed to be the fastest GC technique Allocation is very cheap Just increment the heap pointer Collection is relatively cheap Especially if there is a lot of garbage Only touch reachable objects (does not touch garbage)

Stop and Copy: Evaluation Stop and copy is generally believed to be the fastest GC technique Allocation is very cheap Just increment the heap pointer Collection is relatively cheap Especially if there is a lot of garbage Only touch reachable objects (does not touch garbage) But some languages don t allow copying (C, C++) Why?

Why Doesn t C Allow Copying? Garbage collection relies on being able to find all reachable objects And it needs to find all pointers in an object

Why Doesn t C Allow Copying? Garbage collection relies on being able to find all reachable objects And it needs to find all pointers in an object In C or C++ it is impossible to identify the contents of objects in memory E.g., how can you tell that a sequence of two memory words is a list cell (with data and next fields) or a binary tree node (with a left and right fields)? Thus we cannot tell where all the pointers are

Conservative Garbage Collection But it is Ok to be conservative: If a memory word looks like a pointer it is considered a pointer it must be aligned it must point to a valid address in the data segment All such pointers are followed and we overestimate the reachable objects

Conservative Garbage Collection But it is Ok to be conservative: If a memory word looks like a pointer it is considered a pointer it must be aligned it must point to a valid address in the data segment All such pointers are followed and we overestimate the reachable objects But we still cannot move objects because we cannot update pointers to them What if what we thought to be a pointer is actually an account number?

Reference Counting [Collins 1960] Rather that wait for memory to be exhausted, try to collect an object when there are no more pointers to it

Reference Counting [Collins 1960] Rather that wait for memory to be exhausted, try to collect an object when there are no more pointers to it Store in each object the number of pointers to that object This is the reference count 3

Reference Counting [Collins 1960] Rather that wait for memory to be exhausted, try to collect an object when there are no more pointers to it Store in each object the number of pointers to that object This is the reference count Each assignment operation has to manipulate the reference count 3

Implementation of Reference Counting new returns an object with a reference count of 1 Let rc(x) be the reference count of x Assume x,y point to object o,p Every assignment x y must be changed: rc(p) rc(p) + 1 rc(o) rc(o) - 1 if(rc(o) == 0) then free o x y o p

Reference Counting: Evaluation Advantages: Easy to implement Collects garbage incrementally without large pauses in the execution

Reference Counting: Evaluation Advantages: Easy to implement Collects garbage incrementally without large pauses in the execution Disadvantages: Manipulating reference counts at each assignment is very slow rc(p) rc(p) + 1 rc(o) rc(o) - 1 if(rc(o) == 0) then free o

Reference Counting: Evaluation Advantages: Easy to implement Collects garbage incrementally without large pauses in the execution Disadvantages: Manipulating reference counts at each assignment is very slow Cannot collect circular structures x 2 1

Reference Counting: Evaluation Advantages: Easy to implement Collects garbage incrementally without large pauses in the execution Disadvantages: Manipulating reference counts at each assignment is very slow Cannot collect circular structures x 1 1

Garbage Collection: Evaluation Automatic memory management avoids some serious storage bugs

Garbage Collection: Evaluation Automatic memory management avoids some serious storage bugs But it takes away control from the programmer e.g., layout of data in memory e.g., when is memory deallocated

Garbage Collection: Evaluation Automatic memory management avoids some serious storage bugs But it takes away control from the programmer e.g., layout of data in memory e.g., when is memory deallocated Most garbage collection implementation stop the execution during collection not acceptable in real-time applications

Garbage Collection: Evaluation Automatic memory management avoids some serious storage bugs But it takes away control from the programmer e.g., layout of data in memory e.g., when is memory deallocated Most garbage collection implementation stop the execution during collection not acceptable in real-time applications Memory leaks possible - Do we need a AST after generating intermediate language?

Garbage Collection: Evaluation Garbage collection is going to be around for a while Researchers are working on advanced garbage collection algorithms: Concurrent: allow the program to run while the collection is happening Generational: do not scan long-lived objects at every collection (JVM uses this kind) Parallel: several collectors working in parallel