CS 326 Programming Languages, Concepts and Implementation Instructor: Mircea Nicolescu Lecture 18.

Slides:



Advertisements
Similar presentations
Garbage collection David Walker CS 320. Where are we? Last time: A survey of common garbage collection techniques –Manual memory management –Reference.
Advertisements

Procedures. 2 Procedure Definition A procedure is a mechanism for abstracting a group of related operations into a single operation that can be used repeatedly.
Introduction to Memory Management. 2 General Structure of Run-Time Memory.
Run-time Environment for a Program different logical parts of a program during execution stack – automatically allocated variables (local variables, subdivided.
Names and Bindings.
Lecture 10: Heap Management CS 540 GMU Spring 2009.
Garbage Collection What is garbage and how can we deal with it?
1 Object Lifetime and Garbage Collection (Section 10.3 & 7.7) CSCI 431 Programming Languages Fall 2003 A modification of slides developed by Felix Hernandez-Campos.
Garbage Collection  records not reachable  reclaim to allow reuse  performed by runtime system (support programs linked with the compiled code) (support.
Various languages….  Could affect performance  Could affect reliability  Could affect language choice.
CPSC 388 – Compiler Design and Construction
Chapter 8 Runtime Support. How program structures are implemented in a computer memory? The evolution of programming language design has led to the creation.
Memory Management. History Run-time management of dynamic memory is a necessary activity for modern programming languages Lisp of the 1960’s was one of.
CS 355 – Programming Languages
Chapter 9 Subprogram Control Consider program as a tree- –Each parent calls (transfers control to) child –Parent resumes when child completes –Copy rule.
Memory Allocation. Three kinds of memory Fixed memory Stack memory Heap memory.
1 Names, Scopes and Bindings. 2 Names Kinds of names Kinds of names Variables, functions, classes, types, labels, blocks, operators, tasks, etc. Variables,
Run-Time Storage Organization
Run time vs. Compile time
The environment of the computation Declarations introduce names that denote entities. At execution-time, entities are bound to values or to locations:
1 Run time vs. Compile time The compiler must generate code to handle issues that arise at run time Representation of various data types Procedure linkage.
Names and Bindings Introduction Names Variables The concept of binding Chapter 5-a.
SEG Advanced Software Design and Reengineering TOPIC L Garbage Collection Algorithms.
Chapter 8 :: Subroutines and Control Abstraction
COP4020 Programming Languages
Name Binding and Object Lifetimes Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture.
CS3012: Formal Languages and Compilers The Runtime Environment After the analysis phases are complete, the compiler must generate executable code. The.
CS 403: Programming Languages Lecture 2 Fall 2003 Department of Computer Science University of Alabama Joel Jones.
CSC3315 (Spring 2009)1 CSC 3315 Programming Languages Hamid Harroud School of Science and Engineering, Akhawayn University
Runtime Environments Compiler Construction Chapter 7.
Programming Language Principles Lecture 24 Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Subroutines.
Compiler Construction
Chapter 5: Programming Languages and Constructs by Ravi Sethi Activation Records Dolores Zage.
Copyright © 2005 Elsevier Chapter 8 :: Subroutines and Control Abstraction Programming Language Pragmatics Michael L. Scott.
Basic Semantics Associating meaning with language entities.
1 Control Abstraction (Section ) CSCI 431 Programming Languages Fall 2003 A compilation of material developed by Felix Hernandez-Campos and Michael.
Runtime Environments. Support of Execution  Activation Tree  Control Stack  Scope  Binding of Names –Data object (values in storage) –Environment.
1 Records Record aggregate of data elements –Possibly heterogeneous –Elements/slots are identified by names –Elements in same fixed order in all records.
C++ Memory Overview 4 major memory segments Key differences from Java
CS 326 Programming Languages, Concepts and Implementation Instructor: Mircea Nicolescu Lecture 9.
COMP3190: Principle of Programming Languages
ISBN Chapter 6 Data Types Pointer Types Reference Types Memory Management.
Concepts of programming languages Chapter 5 Names, Bindings, and Scopes Lec. 12 Lecturer: Dr. Emad Nabil 1-1.
1 Lecture 22: Object Lifetime and Garbage Collection (Section 10.3 & 7.7) CSCI 431 Programming Languages Fall 2002 A modification of slides developed by.
Lecture 19: Control Abstraction (Section )
Programming Languages and Design Lecture 6 Names, Scopes and Binding Instructor: Li Ma Department of Computer Science Texas Southern University, Houston.
1 Lecture07: Memory Model 5/2/2012 Slides modified from Yin Lou, Cornell CS2022: Introduction to C.
RUNTIME ENVIRONMENT AND VARIABLE BINDINGS How to manage local variables.
LECTURE 13 Names, Scopes, and Bindings: Memory Management Schemes.
Names, Scope, and Bindings Programming Languages and Paradigms.
LECTURE 19 Subroutines and Parameter Passing. ABSTRACTION Recall: Abstraction is the process by which we can hide larger or more complex code fragments.
Runtime Environments Chapter 7. Support of Execution  Activation Tree  Control Stack  Scope  Binding of Names –Data object (values in storage) –Environment.
Data Types Chapter 6: Data Types Lectures # 13. Topics Chapter 6: Data Types 2 Introduction Primitive Data Types Character String Types Array Types Associative.
Code Generation Instruction Selection Higher level instruction -> Low level instruction Register Allocation Which register to assign to hold which items?
Object Lifetime and Pointers
Storage Allocation Mechanisms
CS 326 Programming Languages, Concepts and Implementation
CS 326 Programming Languages, Concepts and Implementation
Type Checking, and Scopes
CS 326 Programming Languages, Concepts and Implementation
CS 153: Concepts of Compiler Design November 28 Class Meeting
Concepts of programming languages
Chapter 9 :: Subroutines and Control Abstraction
Storage.
Chap. 8 :: Subroutines and Control Abstraction
Chap. 8 :: Subroutines and Control Abstraction
Dynamic Memory.
RUN-TIME STORAGE Chuen-Liang Chen Department of Computer Science
CMPE 152: Compiler Design May 2 Class Meeting
Presentation transcript:

CS 326 Programming Languages, Concepts and Implementation Instructor: Mircea Nicolescu Lecture 18

2 Dangling References How are objects deallocated? Storage classes: −static - never deallocated, same lifetime as the program −stack - deallocated automatically on subroutine return −heap - explicit or implicit deallocation Explicit deallocation in Pascal: dispose (my_ptr); In C: free (my_ptr); In C++: delete my_ptr;// before deallocation, also calls the destructor for the object Implicit deallocation −garbage collection

3 Dangling References Dangling reference - a pointer that no longer points to a live object Produced in the context of heap allocation: p = new int ; r = p ; delete r ; *p = 3;// crash!! Produced in the context of stack allocation (not in Pascal - has only pointers to heap objects): int* f () { int x; return &x; } void main () { int *p; p = f(); *p = 3;// crash!! }

4 Dangling References Dangling references can only be produced in languages with explicit deallocation. Why? −Programmer may deallocate an object that is still referred by live pointers −Garbage collection will check if an object still has references to it before deleting it Why do we need to detect dangling references? −Need to warn the programmer - generate an error, not silently retrieve some garbage Mechanisms to detect dangling references −Tombstones −Locks and keys

5 Tombstones Extra level of indirection −the pointer points to the tombstone −the tombstone points to the object Deallocate an object - put a special value in the tombstone For each object allocated dynamically - also allocate a tombstone

6 Tombstones Properties −catch all dangling references −handle both heap and stack objects −make storage compaction easier – why? − when moving blocks, need to change only addresses in tombstones, not in the pointers Time complexity - overhead: −creation of tombstones when allocating objects −checking validity on every access −double indirection Space complexity - need extra space for tombstones −when are they deallocated? −two approaches: −never deallocate them −add a reference count to each tombstone - deallocate when count is zero

7 Locks and Keys Allocation - generate a number, store it in the object (lock) and in the pointer (key) Access - check if the key matches the lock Deallocation - put a special value in the lock

8 Locks and Keys Properties −do not guarantee to catch all dangling references - why? −a reused block may get the same lock number - however, it is a low probability −used to handle only heap objects – why? −to catch stack objects - would need to have locks on every local variable and argument Time complexity - overhead: −comparing locks and keys on every access −however, no double indirection Space complexity −extra space for locks in every heap object −extra space for keys in every pointer −however, no additional entities (tombstones) to be deallocated

9 Garbage Collection −Advantages: implementation simplicity, speed −Disadvantages: burden on programmer, may produce garbage (memory leaks) or dangling references Explicit deallocation of heap objects Automatic deallocation of heap objects (garbage collection) −Advantages: convenience for programmer, safety (no memory leaks or dangling references) −Disadvantages: complex implementation, run-time overhead Garbage collection −essential for functional languages - frequent construction and return of objects from functions −increasingly used in imperative languages (Clu, Ada, Java) −mechanisms: −reference counts −mark-and-sweep

10 Reference Counts How do we know when a heap object is no longer useful? −when there are no pointers to it Solution −in each object keep a reference counter = the number of pointers referring the object −when allocating the object: p = new int;// refcnt of new object ← 1 −when assigning pointers: p = r;// refcnt of object referred by p -- // refcnt of object referred by r ++ −when the reference count is zero → can destroy it

11 Reference Counts Problems: −Objects that contain pointers: p = new chr_tree;... p = r;// if the object referred by p can be deleted (refcnt = 0), need to recursively follow pointers within it to decrement refcnt for those objects, and delete them as well if their refcnt is zero −Pointers declared as local variables: void f ( int * x ) { int i; int * p = x;// refcnt of object referred by x ++ return;// } all local variables will die here - must find all those which are pointers (like p) and decrement refcnts −Solution - use type descriptors −at the beginning of each record - specify which fields are pointers −in each stack frame - specify which local variables are pointers

12 Reference Counts Problem - circular lists: The objects in the list are not reachable, but their reference counts are non-zero

13 Mark-and-Sweep Collection When the free space becomes low: 1.walk through the heap, and mark each block (tentatively) as "useless" 2.recursively explore all pointers in the program, and mark each encountered block as "useful" 3.walk again through the heap, and delete every "useless" block (could not be reached) To find all pointers -use type descriptors To explore recursively -need a stack (to be able to return) −maximum length of stack = the longest chain of pointers −problem - maybe not enough space for a stack (the free space is already low) −solution - exploration via pointer reversal

14 Mark-and-Sweep Collection Exploration via pointer reversal: Before moving from current to next block, reverse the pointer that is followed, to refer back to previous block When returning, restore the pointer During exploration, the currently explored path will have all pointers reversed, to trace the way back

15 Storage Compaction Storage compaction - reduce external fragmentation −elegant solution – stop-and-copy Stop-and-copy −achieve compaction and garbage collection and simultaneously eliminate steps 1 and 3 from mark-and-sweep −divide the heap in two halves −all allocations happen in first half −when memory is low −recursively explore all pointers in the program, move each encountered block to the second half, and change the pointer to it accordingly −swap the notion of first and second half

16 Garbage Collection Stop-and-copy – advantage over standard mark-and-sweep Significant difference between reference counts strategies and mark-and-sweep strategies −no more walks ("sweeps") through the entire heap −overhead proportional to the number of used blocks, instead of the total number of blocks −reference counts - when an object is no longer needed, it can be immediately reclaimed −mark-and-sweep - "stop-the-world" effect: pause program execution to reclaim all the garbage

17 Language Specification General issues in the design and implementation of a language: −Syntax and semantics −Naming, scopes and bindings −Control flow −Data types −Subroutines

18 Subroutines and Control Abstraction Abstraction - associate a name with a potentially complex program fragment −consider the fragment in terms of its purpose, not implementation Control abstraction - purpose corresponds to an operation −subroutines (functions, procedures), coroutines, exceptions Data abstraction - purpose is to represent information −generic data structures, classes (also include control abstraction) Subroutine parameters −formal parameters - specified in subroutine definition −actual parameters - provided when the subroutine is called

19 Stack Layout Recall allocation strategies: Static −code −global variables −"own" (static) local variables −explicit constants (including strings, sets, other aggregates) −small scalars may be stored in the instructions themselves Stack −parameters −local variables −temporaries −bookkeeping information Heap −dynamic allocation

20 Stack Layout When calling a subroutine, push a new entry on the stack - stack frame (activation record) When retuning from a subroutine, pop its frame from the stack stack pointer register (sp) - address of the first unused location at top of stack frame pointer register (fp) - address within current stack frame

21 Announcements Readings −Rest of Chapter 7