Memory Management. Didactic Module 14 Programming Languages - EEL670 1

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

Lecture 13: Garbage Collection

Run-Time Environments/Garbage Collection

Robust Memory Management Schemes

G Programming Languages - Fall 2012

CS61C : Machine Structures

Heap Management. Heap Allocation

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

Deallocation Mechanisms. User-controlled Deallocation. Automatic Garbage Collection

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

Dynamic Memory Allocation

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

Run-time Environments -Part 3

A First Look At Java. Didactic Module 13 Programming Languages - EEL670 1

CS 241 Honors Memory

Lecture Notes on Garbage Collection

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

CMSC 330: Organization of Programming Languages

CS61C Midterm Review on C & Memory Management

CMSC 330: Organization of Programming Languages

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

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

Engine Support System. asyrani.com

Dynamic Memory Management! Goals of this Lecture!

Run-time Environments - 3

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

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

Programming Language Implementation

Dynamic Memory Allocation

Automatic Garbage Collection

Implementation Garbage Collection

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

Dynamic Storage Allocation

Dynamic Memory Management

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

CS 33. Storage Allocation. CS33 Intro to Computer Systems XXVII 1 Copyright 2017 Thomas W. Doeppner. All rights reserved.

Structure of Programming Languages Lecture 10

Compiler Construction

Dynamic Memory Management

Run Time Environment

Lecture 13: Complex Types and Garbage Collection

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

Compiler Construction

Today. Dynamic Memory Allocation: Basic Concepts. Dynamic Memory Allocation. Dynamic Memory Allocation. malloc Example. The malloc Package

Q1: /8 Q2: /30 Q3: /30 Q4: /32. Total: /100

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

Name, Scope, and Binding. Outline [1]

CA341 - Comparative Programming Languages

Habanero Extreme Scale Software Research Project

Dynamic Memory Allocation: Basic Concepts

Advances in Programming Languages: Regions

CS 345. Garbage Collection. Vitaly Shmatikov. slide 1

Lecture Notes on Garbage Collection

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

Dynamic Memory Allocation: Basic Concepts

Programming Languages

Automatic Memory Management

Memory management. Johan Montelius KTH

Project. there are a couple of 3 person teams. a new drop with new type checking is coming. regroup or see me or forever hold your peace

Compiler Construction D7011E

Programming Languages Third Edition. Chapter 10 Control II Procedures and Environments

Heap Management portion of the store lives indefinitely until the program explicitly deletes it C++ and Java new Such objects are stored on a heap

CS399 New Beginnings. Jonathan Walpole

Today. Dynamic Memory Allocation: Basic Concepts. Dynamic Memory Allocation. Dynamic Memory Allocation. malloc Example. The malloc Package

CSCI-UA /2. Computer Systems Organization Lecture 19: Dynamic Memory Allocation: Basics

Review! Lecture 5 C Memory Management !

CS61C : Machine Structures

Programs in memory. The layout of memory is roughly:

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

Dynamic Memory Allocation. Basic Concepts. Computer Organization 4/3/2012. CSC252 - Spring The malloc Package. Kai Shen

CS201 Some Important Definitions

Exploiting the Behavior of Generational Garbage Collector

Types II. Hwansoo Han

Garbage Collection Algorithms. Ganesh Bikshandi

Introduction to Computer Systems /18 243, fall th Lecture, Oct. 22 th

Memory Allocation. Copyright : University of Illinois CS 241 Staff 1

Memory Allocation II. CSE 351 Autumn Instructor: Justin Hsia

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

Dynamic Memory Allocation: Advanced Concepts

ECE 2035 Programming HW/SW Systems Fall problems, 5 pages Exam Three 28 November 2012

Fun facts about recursion

Object Oriented Programming: In this course we began an introduction to programming from an object-oriented approach.

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

Advanced Programming & C++ Language

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

Example. program sort; var a : array[0..10] of integer; procedure readarray; : function partition (y, z :integer) :integer; var i, j,x, v :integer; :

Dynamic Memory Allocation I Nov 5, 2002

CS 330 Lecture 18. Symbol table. C scope rules. Declarations. Chapter 5 Louden Outline

Arrays & Linked Lists

Computer Science 62. Bruce/Mawhorter Fall 16. Midterm Examination. October 5, Question Points Score TOTAL 52 SOLUTIONS. Your name (Please print)

Parallel GC. (Chapter 14) Eleanor Ainy December 16 th 2014

Short Notes of CS201

Garbage Collection (1)

Garbage Collection. Steven R. Bagley

Lectures 13 & 14. memory management

Programming II (CS300)

Dynamic Data Structures (II)

Dynamic Memory Allocation I

About this exam review

Heap, Variables, References, and Garbage. CS152. Chris Pollett. Oct. 13, 2008.

Transcription:

Memory Management Didactic Module 14 Programming Languages - EEL670 1

Dynamic Memory Allocation Lots of things need memory at runtime: Activation records Objects Explicit allocations: new, malloc, etc. Implicit allocations: strings, file buffers, arrays with dynamically varying size, etc. Language systems provide an important hidden player: runtime memory management Didactic Module 14 Programming Languages - EEL670 2

Outline Memory model using Java arrays Stacks Heaps Current heap links Garbage collection Didactic Module 14 Programming Languages - EEL670 3

Memory Model For now, assume that the OS grants each running program one or more fixed-size regions of memory for dynamic allocation We will model these regions as Java arrays To see examples of memory management code And, for practice with Java Didactic Module 14 Programming Languages - EEL670 4

Declaring An Array A Java array declaration: int[] a = null; Array types are reference types an array is really an object, with a little special syntax The variable a above is initialized to null It can hold a reference to an array of int values, but does not yet Didactic Module 14 Programming Languages - EEL670 5

Creating An Array Use new to create an array object: int[] a = null; a = new int[100]; We could have done it with one declaration statement, like this: int[] a = new int[100]; Didactic Module 14 Programming Languages - EEL670 6

Using An Array int i = 0; while (i<a.length) { a[i] = 5; i++; } Use a[i] to refer to an element (as lvalue or rvalue): a is an array reference expression and i is an int expression Use a.length to access length Array indexes are 0..(a.length-1) Didactic Module 14 Programming Languages - EEL670 7

Memory Managers In Java public class MemoryManager { private int[] memory; } /** * MemoryManager constructor. * @param initialmemory int[] of memory to manage */ public MemoryManager(int[] initialmemory) { memory = initialmemory; } We will show Java implementations this way. The initialmemory array is the memory region provided by the operating system. Didactic Module 14 Programming Languages - EEL670 8

Outline Memory model using Java arrays Stacks Heaps Current heap links Garbage collection Didactic Module 14 Programming Languages - EEL670 9

Stacks Of Activation Records For almost all languages, activation records must be allocated dynamically For many, it suffices to allocate on call and deallocate on return This produces a stack of activation records: push on call, pop on return A simple memory management problem Didactic Module 14 Programming Languages - EEL670 10

A Stack Illustration top: 8 7: 6: 5: 4: 3: 2: 1: 0: An empty stack of 8 words. The stack will grow down, from high addresses to lower addresses. A reserved memory location (perhaps a register) records the address of the lowest allocated word. Didactic Module 14 Programming Languages - EEL670 11

top: 4 7: 6: 5: 4: 3: 2: 1: 0: 8 first activation record The program calls m.push(3), which returns 5: the address of the first of the 3 words allocated for an activation record. Memory management uses an extra word to record the previous value of top. Didactic Module 14 Programming Languages - EEL670 12

top: 1 7: 6: 5: 4: 3: 2: 1: 0: 8 first activation record second activation record 4 The program calls m.push(2), which returns 2: the address of the first of the 2 words allocated for an activation record. The stack is now full there is not room even for m.push(1). For m.pop(), just do top = memory[top] to return to previous configuration. Didactic Module 14 Programming Languages - EEL670 13

A Java Stack Implementation public class StackManager { private int[] memory; // the memory we manage private int top; // index of top stack block /** * StackManager constructor. * @param initialmemory int[] of memory to manage */ public StackManager(int[] initialmemory) { memory = initialmemory; top = memory.length; } Didactic Module 14 Programming Languages - EEL670 14

/** * Allocate a block and return its address. * @param requestsize int size of block, > 0 * @return block address * @throws StackOverflowError if out of stack space */ public int push(int requestsize) { int oldtop = top; top -= (requestsize+1); // extra word for oldtop if (top<0) throw new StackOverflowError(); memory[top] = oldtop; return top+1; } The throw statement and exception handling are introduced in Chapter 17. Didactic Module 14 Programming Languages - EEL670 15

} /** * Pop the top stack frame. This works only if the * stack is not empty. */ public void pop() { top = memory[top]; } Didactic Module 14 Programming Languages - EEL670 16

Outline Memory model using Java arrays Stacks Heaps Current heap links Garbage collection Didactic Module 14 Programming Languages - EEL670 17

The Heap Problem Stack order makes implementation easy Not always possible: what if allocations and deallocations can come in any order? A heap is a pool of blocks of memory, with an interface for unordered runtime memory allocation and deallocation There are many mechanisms for this Didactic Module 14 Programming Languages - EEL670 18

First Fit A linked list of free blocks, initially containing one big free block To allocate: Search free list for first adequate block If there is extra space in the block, return the unused portion at the upper end to the free list Allocate requested portion (at the lower end) To free, just add to the front of the free list Didactic Module 14 Programming Languages - EEL670 19

Heap Illustration A heap manager m with a memory array of 10 words, initially empty. The link to the head of the free list is held in freestart. Every block, allocated or free, has its length in its first word. Free blocks have free-list link in their second word, or 1 at the end of the free list. 9: 8: 7: 6: 5: 4: 3: 2: freestart: 0 1: 0: -1 10 Didactic Module 14 Programming Languages - EEL670 20

p1=m.allocate(4); 9: p1 will be 1 the address of the first of four allocated words. An extra word holds the block length. Remainder of the big free block was returned to the free list. freestart: 5 8: 7: 6: 5: 4: 3: 2: 1: 0: -1 5 5 first allocated block Didactic Module 14 Programming Languages - EEL670 21

p1=m.allocate(4); p2=m.allocate(2); p2 will be 6 the address of the first of two allocated words. An extra word holds the block length. Remainder of the free block was returned to the free list. freestart: 8 9: 8: 7: 6: 5: 4: 3: 2: 1: 0: -1 2 second allocated block 3 5 first allocated block Didactic Module 14 Programming Languages - EEL670 22

p1=m.allocate(4); p2=m.allocate(2); m.deallocate(p1); Deallocates the first allocated block. It returns to the head of the free list. freestart: 0 9: 8: 7: 6: 5: 4: 3: 2: 1: 0: -1 2 second allocated block 3 8 5 Didactic Module 14 Programming Languages - EEL670 23

p1=m.allocate(4); p2=m.allocate(2); m.deallocate(p1); p3=m.allocate(1); p3 will be 1 the address of the allocated word. Notice that there were two suitable blocks. The other one would have been an exact fit. (Best Fit is another possible mechanism.) freestart: 2 9: 8: 7: 6: 5: 4: 3: 2: 1: 0: -1 2 second allocated block 3 8 3 2 third allocated block Didactic Module 14 Programming Languages - EEL670 24

A Java Heap Implementation public class HeapManager { static private final int NULL = -1; // null link public int[] memory; // the memory we manage private int freestart; // start of the free list /** * HeapManager constructor. * @param initialmemory int[] of memory to manage */ public HeapManager(int[] initialmemory) { memory = initialmemory; memory[0] = memory.length; // one big free block memory[1] = NULL; // free list ends with it freestart = 0; // free list starts with it } Didactic Module 14 Programming Languages - EEL670 25

/** * Allocate a block and return its address. * @param requestsize int size of block, > 0 * @return block address * @throws OutOfMemoryError if no block big enough */ public int allocate(int requestsize) { int size = requestsize + 1; // size with header // Do first-fit search: linear search of the free // list for the first block of sufficient size. int p = freestart; // head of free list int lag = NULL; while (p!=null && memory[p]<size) { lag = p; // lag is previous p p = memory[p+1]; // link to next block } if (p==null) // no block large enough throw new OutOfMemoryError(); int nextfree = memory[p+1]; // block after p Didactic Module 14 Programming Languages - EEL670 26

} // Now p is the index of a block of sufficient size, // and lag is the index of p's predecessor in the // free list, or NULL, and nextfree is the index of // p's successor in the free list, or NULL. // If the block has more space than we need, carve // out what we need from the front and return the // unused end part to the free list. int unused = memory[p]-size; // extra space if (unused>1) { // if more than a header's worth nextfree = p+size; // index of the unused piece memory[nextfree] = unused; // fill in size memory[nextfree+1] = memory[p+1]; // fill in link memory[p] = size; // reduce p's size accordingly } // Link out the block we are allocating and done. if (lag==null) freestart = nextfree; else memory[lag+1] = nextfree; return p+1; // index of useable word (after header) Didactic Module 14 Programming Languages - EEL670 27

} /** * Deallocate an allocated block. This works only if * the block address is one that was returned by * allocate and has not yet been deallocated. * @param address int address of the block */ public void deallocate(int address) { int addr = address-1; memory[addr+1] = freestart; freestart = addr; } Didactic Module 14 Programming Languages - EEL670 28

A Problem Consider this sequence: p1=m.allocate(4); p2=m.allocate(4); m.deallocate(p1); m.deallocate(p2); p3=m.allocate(7); Final allocate will fail: we are breaking up large blocks but never reversing the process Need to coalesce adjacent free blocks Didactic Module 14 Programming Languages - EEL670 29

A Solution We can implement a smarter deallocate method: Maintain the free list sorted in address order When freeing, look at the previous free block and the next free block If adjacent, coalesce This is a lot more work than just returning the block to the head of the free list Didactic Module 14 Programming Languages - EEL670 30

/** * Deallocate an allocated block. This works only if * the block address is one that was returned by * allocate and has not yet been deallocated. * @param address int address of the block */ public void deallocate(int address) { int addr = address-1; // real start of the block // Find the insertion point in the sorted free list // for this block. int p = freestart; int lag = NULL; while (p!=null && p<addr) { lag = p; p = memory[p+1]; } Didactic Module 14 Programming Languages - EEL670 31

// Now p is the index of the block to come after // ours in the free list, or NULL, and lag is the // index of the block to come before ours in the // free list, or NULL. // If the one to come after ours is adjacent to it, // merge it into ours and restore the property // described above. if (addr+memory[addr]==p) { memory[addr] += memory[p]; // add its size to ours p = memory[p+1]; // } Didactic Module 14 Programming Languages - EEL670 32

} if (lag==null) { // ours will be first free freestart = addr; memory[addr+1] = p; } else if (lag+memory[lag]==addr) { // block before is // adjacent to ours memory[lag] += memory[addr]; // merge ours into it memory[lag+1] = p; } else { // neither: just a simple insertion memory[lag+1] = addr; memory[addr+1] = p; } Didactic Module 14 Programming Languages - EEL670 33

Quick Lists Small blocks tend to be allocated and deallocated much more frequently A common optimization: keep separate free lists for popular (small) block sizes On these quick lists, blocks are one size Delayed coalescing: free blocks on quick lists are not coalesced right away (but may have to be coalesced eventually) Didactic Module 14 Programming Languages - EEL670 34

Fragmentation When free regions are separated by allocated blocks, so that it is not possible to allocate all of free memory as one block More generally: any time a heap manager is unable to allocate memory even though free If it allocated more than requested If it does not coalesce adjacent free blocks And so on Didactic Module 14 Programming Languages - EEL670 35

p1=m.allocate(4); p2=m.allocate(1); m.deallocate(p1); p3=m.allocate(5); The final allocation will fail because of fragmentation. 9: 8: -1 7: 6: 5: 4: 3 second allocated block 2 3: 2: freestart: 0 1: 0: 7 5 Didactic Module 14 Programming Languages - EEL670 36

Other Heap Mechanisms An amazing variety Three major issues: Placement where to allocate a block Splitting when and how to split large blocks Coalescing when and how to recombine Many other refinements Didactic Module 14 Programming Languages - EEL670 37

Placement Where to allocate a block Our mechanism: first fit from FIFO free list Some mechanisms use a similar linked list of free blocks: first fit, best fit, next fit, etc. Some mechanisms use a more scalable data structure like a balanced binary tree Didactic Module 14 Programming Languages - EEL670 38

Splitting When and how to split large blocks Our mechanism: split to requested size Sometimes you get better results with less splitting just allocate more than requested A common example: rounding up allocation size to some multiple Didactic Module 14 Programming Languages - EEL670 39

Coalescing When and how to recombine adjacent free blocks We saw several varieties: No coalescing Eager coalescing Delayed coalescing (as with quick lists) Didactic Module 14 Programming Languages - EEL670 40

Outline Memory model using Java arrays Stacks Heaps Current heap links Garbage collection Didactic Module 14 Programming Languages - EEL670 41

Current Heap Links So far, the running program is a black box: a source of allocations and deallocations What does the running program do with addresses allocated to it? Some systems track current heap links A current heap link is a memory location where a value is stored that the running program will use as a heap address Didactic Module 14 Programming Languages - EEL670 42

Tracing Current Heap Links a: b: 2 c: 1 (activation record for main) free the stack start: (an IntList) free head: 2 tail: null (a ConsCell) free head: 1 tail: (a ConsCell) free the heap IntList a = new IntList(null); int b = 2; int c = 1; a = a.cons(b); a = a.cons(c); Where are the current heap links in this picture? Didactic Module 14 Programming Languages - EEL670 43

To Find Current Heap Links Start with the root set: memory locations outside of the heap with links into the heap Active activation records (if on the stack) Static variables, etc. For each memory location in the set, look at the allocated block it points to, and add all the memory locations in that block Repeat until no new locations are found Didactic Module 14 Programming Languages - EEL670 44

Discarding Impossible Links Depending on the language and implementation, we may be able to discard some locations from the set: If they do not point into allocated heap blocks If they do not point to allocated heap blocks (Java, but not C) If their dynamic type rules out use as heap links If their static type rules out use as heap links (Java, but not C) Didactic Module 14 Programming Languages - EEL670 45

Errors In Current Heap Links Exclusion errors: a memory location that actually is a current heap link is left out Unused inclusion errors: a memory location is included, but the program never actually uses the value stored there Used inclusion errors: a memory location is included, but the program uses the value stored there as something other than a heap address as an integer, for example Didactic Module 14 Programming Languages - EEL670 46

Errors Are Unavoidable For heap manager purposes, exclusion errors are unacceptable We must include a location if it might be used as a heap link This makes unused inclusion errors unavoidable Depending on the language, used inclusions may also be unavoidable Didactic Module 14 Programming Languages - EEL670 47

Used Inclusion Errors In C Static type and runtime value may be of no use in telling how a value will be used Variable x may be used either as a pointer or as an array of four characters union { char *p; char tag[4]; } x; Didactic Module 14 Programming Languages - EEL670 48

Heap Compaction One application for current heap links Manager can move allocated blocks: Copy the block to a new location Update all links to (or into) that block So it can compact the heap, moving all allocated blocks to one end, leaving one big free block and no fragmentation Didactic Module 14 Programming Languages - EEL670 49

Outline Memory model using Java arrays Stacks Heaps Current heap links Garbage collection Didactic Module 14 Programming Languages - EEL670 50

Some Common Pointer Errors type p: ^Integer; begin new(p); p^ := 21; dispose(p); p^ := p^ + 1 end procedure Leak; type p: ^Integer; begin new(p) end; Dangling pointer: this Pascal fragment uses a pointer after the block it points to has been deallocated Memory leak: this Pascal procedure allocates a block but forgets to deallocate it Didactic Module 14 Programming Languages - EEL670 51

Garbage Collection Since so many errors are caused by improper deallocation and since it is a burden on the programmer to have to worry about it why not have the language system reclaim blocks automatically? Didactic Module 14 Programming Languages - EEL670 52

Three Major Approaches Mark and sweep Copying Reference counting Didactic Module 14 Programming Languages - EEL670 53

Mark And Sweep A mark-and-sweep collector uses current heap links in a two-stage process: Mark: find the live heap links and mark all the heap blocks linked to by them Sweep: make a pass over the heap and return unmarked blocks to the free pool Blocks are not moved, so both kinds of inclusion errors are tolerated Didactic Module 14 Programming Languages - EEL670 54

Copying Collection A copying collector divides memory in half, and uses only one half at a time When one half becomes full, find live heap links, and copy live blocks to the other half Compacts as it goes, so fragmentation is eliminated Moves blocks: cannot tolerate used inclusion errors Didactic Module 14 Programming Languages - EEL670 55

Reference Counting Each block has a counter of heap links to it Incremented when a heap link is copied, decremented when a heap link is discarded When counter goes to zero, block is garbage and can be freed Does not use current heap links Didactic Module 14 Programming Languages - EEL670 56

Reference Counting Problem circle: link: 2 (activation record) free link: 1 One problem with reference counting: it misses cycles of garbage. free free link: 1 Here, a circularly linked list is pointed to by circle. the stack free the heap Didactic Module 14 Programming Languages - EEL670 57

Reference Counting Problem circle: null link: 1 (activation record) free link: 1 When circle is set to null, the reference counter is decremented. free free link: 1 No reference counter is zero, though all blocks are garbage. the stack free the heap Didactic Module 14 Programming Languages - EEL670 58

Reference Counting Problem with cycles of garbage Problem with performance generally, since the overhead of updating reference counters is high One advantage: naturally incremental, with no big pause while collecting Didactic Module 14 Programming Languages - EEL670 59

Garbage Collecting Refinements Generational collectors Divide block into generations according to age Garbage collect in younger generations more often (using previous methods) Incremental collectors Collect garbage a little at a time Avoid the uneven performance of ordinary mark-and-sweep and copying collectors Didactic Module 14 Programming Languages - EEL670 60

Garbage Collecting Languages Some require it: Java, ML Some encourage it: Ada Some make it difficult: C, C++ Even for C and C++ it is possible There are libraries that replace the usual malloc/free with a garbage-collecting manager Didactic Module 14 Programming Languages - EEL670 61

Trends An old idea whose popularity is increasing Good implementations are within a few percent of the performance of systems with explicit deallocation Programmers who like garbage collection feel that the development and debugging time it saves is worth the runtime it costs Didactic Module 14 Programming Languages - EEL670 62

Conclusion Memory management is an important hidden player in language systems Performance and reliability are critical Different techniques are difficult to compare, since every run of every program makes different memory demands An active area of language systems research and experimentation Didactic Module 14 Programming Languages - EEL670 63