LECTURE 13 Names, Scopes, and Bindings: Memory Management Schemes.

Slides:



Advertisements
Similar presentations
Part IV: Memory Management
Advertisements

Dynamic Memory Management
Names and Bindings.
Prof. Necula CS 164 Lecture 141 Run-time Environments Lecture 8.
Various languages….  Could affect performance  Could affect reliability  Could affect language choice.
CS 326 Programming Languages, Concepts and Implementation Instructor: Mircea Nicolescu Lecture 18.
Chapter 8 Runtime Support. How program structures are implemented in a computer memory? The evolution of programming language design has led to the creation.
Stacks and HeapsCS-3013 A-term A Short Digression on Stacks and Heaps CS-3013 Operating Systems A-term 2008 (Slides include materials from Modern.
Digression on Stack and Heaps CS-502 (EMC) Fall A Short Digression on Stacks and Heaps CS-502, Operating Systems Fall 2009 (EMC) (Slides include.
Memory Allocation. Three kinds of memory Fixed memory Stack memory Heap memory.
CS 536 Spring Run-time organization Lecture 19.
3/17/2008Prof. Hilfinger CS 164 Lecture 231 Run-time organization Lecture 23.
1 Names, Scopes and Bindings. 2 Names Kinds of names Kinds of names Variables, functions, classes, types, labels, blocks, operators, tasks, etc. Variables,
Chapter 10 Storage Management Implementation details beyond programmer’s control Storage/CPU time trade-off Binding times to storage.
Run-Time Storage Organization
1 Pertemuan 20 Run-Time Environment Matakuliah: T0174 / Teknik Kompilasi Tahun: 2005 Versi: 1/6.
Run time vs. Compile time
The Concept of Variables
The environment of the computation Declarations introduce names that denote entities. At execution-time, entities are bound to values or to locations:
Run-time Environment and Program Organization
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.
Stacks and HeapsCS-502 Fall A Short Digression Stacks and Heaps CS-502, Operating Systems Fall 2007 (Slides include materials from Operating System.
1 Contents. 2 Run-Time Storage Organization 3 Static Allocation In many early languages, notably assembly and FORTRAN, all storage allocation is static.
Chapter 8 :: Subroutines and Control Abstraction
1 Chapter 5: Names, Bindings and Scopes Lionel Williams Jr. and Victoria Yan CSci 210, Advanced Software Paradigms September 26, 2010.
COP4020 Programming Languages
Chapter 7: Runtime Environment –Run time memory organization. We need to use memory to store: –code –static data (global variables) –dynamic data objects.
Name Binding and Object Lifetimes Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture.
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
SPL/2010 StackVsHeap. SPL/2010 Objectives ● Memory management ● central shared resource in multiprocessing RTE ● memory models that are used in Java and.
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
CSc 453 Runtime Environments Saumya Debray The University of Arizona Tucson.
CPSC 388 – Compiler Design and Construction Runtime Environments.
Copyright © 2005 Elsevier Chapter 8 :: Subroutines and Control Abstraction Programming Language Pragmatics Michael L. Scott.
Basic Semantics Associating meaning with language entities.
COP4020 Programming Languages Subroutines and Parameter Passing Prof. Xin Yuan.
Runtime Environments. Support of Execution  Activation Tree  Control Stack  Scope  Binding of Names –Data object (values in storage) –Environment.
COP4020 Programming Languages Names, Scopes, and Bindings Prof. Xin Yuan.
CS 326 Programming Languages, Concepts and Implementation Instructor: Mircea Nicolescu Lecture 9.
COMP3190: Principle of Programming Languages
RUN-Time Organization Compiler phase— Before writing a code generator, we must decide how to marshal the resources of the target machine (instructions,
CSC 8505 Compiler Construction Runtime Environments.
Concepts of programming languages Chapter 5 Names, Bindings, and Scopes Lec. 12 Lecturer: Dr. Emad Nabil 1-1.
COP4020 Programming Languages Names, Scopes, and Bindings Prof. Robert van Engelen.
Programming Languages and Design Lecture 6 Names, Scopes and Binding Instructor: Li Ma Department of Computer Science Texas Southern University, Houston.
RUNTIME ENVIRONMENT AND VARIABLE BINDINGS How to manage local variables.
COP4020 Programming Languages Names, Scopes, and Bindings Prof. Robert van Engelen (modified by Prof. Em. Chris Lacher)
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.
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
Run-time organization
Lecture 2 Memory management.
Chapter 9 :: Subroutines and Control Abstraction
Chap. 8 :: Subroutines and Control Abstraction
Chap. 8 :: Subroutines and Control Abstraction
Topic 3-b Run-Time Environment
Binding Times Binding is an association between two things Examples:
UNIT V Run Time Environments.
Programming Languages
Name Binding and Object Lifetimes
Run Time Environments 薛智文
Lecture 2 Memory management.
Presentation transcript:

LECTURE 13 Names, Scopes, and Bindings: Memory Management Schemes

REVIEW Last lecture, we introduced the concept of names. Names enable programmers to refer to variables, constants, operations, and types using identifier names rather than low-level hardware addresses. Names are also control and data abstractions of complicated program fragments and data structures. Names must be associated with a number of properties. For example, The type of a variable. The memory location of a compiled function. The value stored in a variable.

REVIEW The act of associating a name with its properties is known as binding. The binding time is the moment when a name becomes bound to one or more of its properties. There are a number of possible binding times. Language design time: when the language is first created. Examples: meaning of keywords such as while or for in C, or the size of the integer data type in Java, the number of primitive types in C++. Language implementation time: when the compiler is implemented. Examples: the size of integers in C.

REVIEW Compilation time. Examples: the types of variables in C, the location of statically allocated variables, and the layout of the activation records of functions. Link time. Example: the address of externally-defined functions such as printf(). Load time. Example: the absolute address of the program in memory prior to execution. Run time. Example: actual values stored in variables; in the case of dynamically-typed languages, types of variables.

REVIEW What are the names used here? int i, x = 0; void main() { for (i = 1; i <= 50; i++) x += do_something(x); }

REVIEW What are the names used here? int i x = void main for do_something etc… int i, x = 0; void main() { for (i = 1; i <= 50; i++) x += do_something(x); }

REVIEW The design of the C language defines the meaning of int, but the implementation of the compiler will decide the range of int. int i, x = 0; void main() { for (i = 1; i <= 50; i++) x += do_something(x); }

REVIEW The types of i and x are bound at compile time, but their values are bound at run time. int i, x = 0; void main() { for (i = 1; i <= 50; i++) x += do_something(x); }

REVIEW If do_something is defined in another file, its implementation is bound at link time. int i, x = 0; void main() { for (i = 1; i <= 50; i++) x += do_something(x); }

REVIEW The addresses of main, i, x, and do_something are bound at load time. int i, x = 0; void main() { for (i = 1; i <= 50; i++) x += do_something(x); }

REVIEW Last time, we also identified the key events in an object’s lifetime and a binding’s lifetime. Object creation. Creation of bindings. The object is manipulated via its binding. Deactivation and reactivation of (temporarily invisible) bindings. (in-and-out of scope). Destruction of bindings. Destruction of object.

STORAGE MANAGEMENT Obviously, objects need to be stored somewhere during the execution of the program. The lifetime of the object, however, generally decides the storage mechanism used. We can divide them up into three categories. The objects that are alive throughout the execution of a program (e.g. global variables). The objects that are alive within a routine (e.g. local variables). The objects whose lifetime can be dynamically changed (the objects that are managed by the ‘new/delete’ constructs).

STORAGE MANAGEMENT The three types of objects correspond to three principal storage allocation mechanisms. Static objects have an absolute storage address that is retained throughout the execution of the program. Global variables and data. Subroutine code and class method code. Stack objects are allocated in last-in first-out order, usually in conjunction with subroutine calls and returns. Actual arguments passed by value to a subroutine. Local variables of a subroutine. Heap objects may be allocated and deallocated at arbitrary times, but require an expensive storage management algorithm. Dynamically allocated data in C++. Java class instances are always stored on the heap.

TYPICAL PROGRAM/DATA LAYOUT IN MEMORY Program code is at the bottom of the memory region (code section). The code section is protected from run- time modification by the OS. Static data objects are stored in the static region. Stack grows downward. Heap grows upward. Stack Heap Static Data Code Lower Addr Higher Addr

STATIC ALLOCATION Program code is statically allocated in most implementations of imperative languages. Statically allocated variables are history sensitive. Global variables keep state during entire program lifetime. Static local variables in C/C++ functions keep state across function invocations. Static data members are “shared” by objects and keep state during program lifetime. Advantage of statically allocated objects is the fast access due to absolute addressing of the object. Can static allocation be used for local variables?

STATIC ALLOCATION Program code is statically allocated in most implementations of imperative languages. Statically allocated variables are history sensitive. Global variables keep state during entire program lifetime Static local variables in C/C++ functions keep state across function invocations. Static data members are “shared” by objects and keep state during program lifetime. Advantage of statically allocated objects is the fast access due to absolute addressing of the object. Can static allocation be used for local variables? No, statically allocated local variables have only one copy of each variable. Cannot deal with the cases when multiple copies of a local variable are alive! When does this happen?

STATIC ALLOCATION IN FORTRAN 77 Fortran 77 has no recursion. Global and local variables are statically allocated as decided by the compiler. Global and local variables are references to absolute addresses. Avoids overhead of creation and destruction of local objects for every subroutine call. Each subroutine in the program has a subroutine frame that is statically allocated. This subroutine frame stores all subroutine- relevant data that is needed to execute. Temporary storage (e.g. for expression evaluation) Local variables Bookkeeping (e.g. saved CPU registers) Return address Subroutine arguments and returns Typical static subroutine frame layout

STACK ALLOCATION Each instance of a subroutine that is active has a subroutine frame (sometimes called activation record) on the run-time stack. Compiler generates subroutine calling sequence to setup frame, call the routine, and to destroy the frame afterwards. Subroutine frame layouts vary between languages, implementations, and machine platforms.

TYPICAL STACK-ALLOCATED SUBROUTINE FRAME Most modern processors have two registers: fp (frame pointer) and sp (stack pointer) to support efficient execution of subroutines in high level languages. A frame pointer (fp) points to the frame of the currently active subroutine at run time. Subroutine arguments, local variables, and return values are accessed by constant address offsets from the fp. Temporary storage (e.g. for expression evaluation) Local variables Bookkeeping (e.g. saved CPU registers) Return address Subroutine arguments and returns fp Higher Addr Lower Addr Typical subroutine frame layout

SUBROUTINE FRAMES ON THE STACK Subroutine frames are pushed and popped onto/from the runtime stack. The stack pointer (sp) points to the next available free space on the stack to push a new frame onto when a subroutine is called. The frame pointer (fp) points to the frame of the currently active subroutine, which is always the topmost frame on the stack. The fp of the previous active frame is saved in the current frame and restored after the call. In this example: M called A A called B B called A M A B A temporaries local variables bookkeeping return address arguments sp fp

EXAMPLE SUBROUTINE FRAME The size of the types of local variables and arguments determines the fp offset in a frame. Example Pascal procedure: procedure P(a:integer, var b:real) (* a is passed by value b is passed by reference, = pointer to b's value*) var foo:integer;(* 4 bytes *) bar:real; (* 8 bytes *) p:^integer; (* 4 bytes *) begin... end Temporary storage (e.g. for expression evaluation) Bookkeeping (16 bytes) Return address to the caller of P (4 bytes) fp Higher Addr Lower Addr 0: a (4 bytes) 4: b (4 bytes) -32: bar (8 bytes) -36: foo (4 bytes) -24: p (4 bytes) fp + 4 fp - 32

HEAP ALLOCATION The heap is used to store objects who lifetime is dynamic. Implicit heap allocation: Done automatically. Java class instances are placed on the heap. Scripting languages and functional languages make extensive use of the heap for storing objects. Some procedural languages allow array declarations with run-time dependent array size. Resizable character strings. Explicit heap allocation: Statements and/or functions for allocation and deallocation. Malloc/free, new/delete.

HEAP ALLOCATION PROBLEMS Heap is a large block of memory (say N bytes). Requests for memory of various sizes may arrive randomly. For example, a program executes ‘new’. Each request may ask for 1 to N bytes. If a request of X bytes is granted, a continuous X bytes in the heap is allocated for the request. The memory will be used for a while and then returned to the system (when the program executes ‘delete’). The problem: how can we make sure memory is allocated such that as many requests as possible are satisfied?

HEAP ALLOCATION EXAMPLE Example: 10KB memory to be managed. r1 = req(1K); r2 = req (2K); r3 = req(4k); free(r2); free(r1); r4 = req(4k); How we assign memory makes a difference! Internal fragment: unused memory within a block. Example: asking for 100 bytes and get a 512 bytes block. External fragment: unused memory between blocks. Even when the total available memory is more than a request, the request cannot be satisfied as in the example.

HEAP ALLOCATION ALGORITHMS Heap allocation is performed by searching the heap for available free space. For example, suppose we want to allocate a new object E of 20 bytes, where would it fit? Object AFreeObject BObject CFreeObject DFree 30 bytes8 bytes10 bytes24 bytes 8 bytes20 bytes

HEAP ALLOCATION ALGORITHMS Heap allocation is performed by searching the heap for available free space. For example, suppose we want to allocate a new object E of 20 bytes, where would it fit? Deletion of objects leaves free blocks in the heap that can be reused How to keep track of free blocks? How to find the right free block for each request? Object AFreeObject BObject CFreeObject DFree 30 bytes8 bytes10 bytes24 bytes 8 bytes20 bytes

HEAP ALLOCATION ALGORITHMS How do we keep track of free blocks? Maintain a linked list of free heap blocks. To satisfy a request (new), search the list to find one block whose size is equal to or larger than the requested size. If the size is equal, remove the block from the free list. If the size is larger, modify the size to (size – requested size). When an object is deleted (freed), the block of memory is returned to the heap. Insert a new block to the free list. If new block can be merged with its neighboring blocks to be a larger block, merge the blocks.

HEAP ALLOCATION ALGORITHMS How do we pick which block should be used for each request? There can be many choices. First-fit: select the first block in the list that is large enough. Best-fit: search the entire list for the smallest free block that is large enough to hold the object.

OTHER HEAP ALLOCATION ALGORITHMS

GARBAGE COLLECTION Explicit manual deallocation errors are among the most expensive and hard to detect problems in real-world applications. If an object is deallocated too soon, a reference to the object becomes a dangling reference. If an object is never deallocated, the program leaks memory. Automatic garbage collection removes all objects from the heap that are not accessible, i.e. are not referenced. Used in Lisp, Scheme, Prolog, Ada, Java, Haskell. Disadvantage is GC overhead, but GC algorithm efficiency has been improved. Not always suitable for real-time processing.

GARBAGE COLLECTION How does it work roughly? The language defines the lifetime of objects. The runtime keeps track of the number of references (bindings) to each object. Increment when a new reference is made, decrement when the reference is destroyed. Can delete when the reference count is 0. Need to determine when a variable is alive or dead based on language specification.

NEXT LECTURE Names, Scopes, and Bindings: Scoping Issues