Name Binding and Object Lifetimes Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture.

Slides:



Advertisements
Similar presentations
Chapter 3:: Names, Scopes, and Bindings
Advertisements

Names, Scope, Memory, and Binding. Name, Scope, and Binding A name is exactly what you think it is – Usually think of identifiers but can be more general.
Names and Bindings.
Run-time organization  Data representation  Storage organization: –stack –heap –garbage collection Programming Languages 3 © 2012 David A Watt,
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.
Chapter 9 Subprogram Control Consider program as a tree- –Each parent calls (transfers control to) child –Parent resumes when child completes –Copy rule.
Chapter 5 Basic Semantics
CS 330 Programming Languages 10 / 16 / 2008 Instructor: Michael Eckmann.
Memory Allocation. Three kinds of memory Fixed memory Stack memory Heap memory.
1 Storage Allocation Operating System Hebrew University Spring 2007.
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
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:
C and Data Structures Baojian Hua
Chapter 5: Memory Management Dhamdhere: Operating Systems— A Concept-Based Approach Slide No: 1 Copyright ©2005 Memory Management Chapter 5.
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.
1 Contents. 2 Run-Time Storage Organization 3 Static Allocation In many early languages, notably assembly and FORTRAN, all storage allocation is static.
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.
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.
1 Binding Time and Storage Allocation (Section ) CSCI 431 Programming Languages Fall 2003 A modification of slides developed by Felix Hernandez-Campos.
1 Chapter 5 Names Bindings Type Checking Scope. 2 High-Level Programming Languages Two main goals:Two main goals: –Machine independence –Ease of programming.
Runtime Environments Compiler Construction Chapter 7.
1 Comp 104: Operating Systems Concepts Java Development and Run-Time Store Organisation.
Compiler Construction
1 Names, Scopes and Bindings Aaron Bloomfield CS 415 Fall
1 Scope Rules (Section 3.3) CSCI 431 Programming Languages Fall 2003 A compilation of material developed by Felix Hernandez-Campos and Michael Scott.
Basic Semantics Associating meaning with language entities.
Scope Rules Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture 11.
CSC3315 (Spring 2008)1 CSC 3315 Subprograms Hamid Harroud School of Science and Engineering, Akhawayn University
COP4020 Programming Languages Names, Scopes, and Bindings Prof. Xin Yuan.
CS 326 Programming Languages, Concepts and Implementation Instructor: Mircea Nicolescu Lecture 9.
Implementing Subprograms What actions must take place when subprograms are called and when they terminate? –calling a subprogram has several associated.
BİL 744 Derleyici Gerçekleştirimi (Compiler Design)1 Run-Time Environments How do we allocate the space for the generated target code and the data object.
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,
Arrays and Pointers Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 23.
國立台灣大學 資訊工程學系 薛智文 98 Spring Run Time Environments (textbook ch# 7.1–7.3 )
CSC 8505 Compiler Construction Runtime Environments.
Concepts of programming languages Chapter 5 Names, Bindings, and Scopes Lec. 12 Lecturer: Dr. Emad Nabil 1-1.
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.
10-1 Chapter 10: Implementing Subprograms The General Semantics of Calls and Returns Implementing “Simple” Subprograms Implementing Subprograms with Stack-Dynamic.
ISBN Chapter 10 Implementing Subprograms.
LECTURE 13 Names, Scopes, and Bindings: Memory Management Schemes.
Names, Scope, and Bindings Programming Languages and Paradigms.
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
Data Types In Text: Chapter 6.
Programming Language Concepts
CS 326 Programming Languages, Concepts and Implementation
CS 326 Programming Languages, Concepts and Implementation
Names, Binding, and Scope
Main Memory Background Swapping Contiguous Allocation Paging
Memory Allocation CS 217.
Topic 3-b Run-Time Environment
Binding Times Binding is an association between two things Examples:
Programming Languages
Name Binding and Object Lifetimes
Run Time Environments 薛智文
Runtime Environments What is in the memory?.
RUN-TIME STORAGE Chuen-Liang Chen Department of Computer Science
Presentation transcript:

Name Binding and Object Lifetimes Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture 10

Names Pervasive in programming languages. Not limited to identifiers ('+' can be a name) Refer to variables, constants, operations, types, files, functions, procedures, modules, etc. Must be tracked in any compiler, usually in a symbol table.

Name Binding Association between a name and the object its represents. The term "object" denotes an entity or concept in the language.

Binding Can Occur at Various Times Language design time. Example: the type referred to by the name int. Language implementation time. Example: the names of library routines in C, e.g. printf.

Binding Can Occur at Various Times (cont’d) Program writing time. Names of data structures, modules. Example: names of debugging flags for C preprocessor: #define DEBUGGING 1... #if DEBUGGING printf(... ); #endif

Binding Can Occur at Various Times (cont’d) Compile time: most bindings take place here. Link time: modules compiled separately are linked together, inter-module references resolved. Example: location of library functions. Load time: program given a load point, translate virtual memory addresses into physical memory addresses.

Binding Can Occur at Various Times (cont’d) Run time. Variables bound to values (memory allocated). Sub-categories include: program start-up time, module entry time, elaboration time (allocate memory for a declared variable), routine call time (set up activation record), execution time.

Terminology Static usually means "before run time". Dynamic usually refers to run time. Tradeoff: In general, Early binding -> greater efficiency, less flexibility. Late binding -> more flexibility, less efficiency.

Examples Early binding: most compiled implementations: C, C++, Java. Compilers analyze semantics, allocate memory in advance, generate smarter code. Can't predict location of a local variable at run time. Can arrange for a variable to live at a fixed offset from a run-time register.

Examples (cont’d) Late binding: most interpreted languages, e.g. RPAL, BASIC, perl, shell script languages, Smalltalk. More analysis done at run time, less efficient.

Static Type-Checking a.k.a. static semantic analysis, a.k.a. contextual constraint analysis: A context-sensitive issue, handled by name associations. Must span arbitrary distances across the tree. Context-free grammar can't do this. Whenever X is used in a program, must find declaration for X, must connect X's USE with its declaration.

Scope Rules Govern which names are visible in which program segments. Declaration: Binding of name and a "descriptor": information about type, value, address, etc.

Examples const x=7; Binds x to (7,type integer). var x:integer; Binds x to (address, type integer), if global Binds x to (stack offset, type integer), if local type T = record y: integer; x: real; end; Binds y to (record offset, type integer). Binds x to (record offset, type real) Binds T to (is_record_type, list of fields)

Object Lifetime and Storage Management Issues: Object creation. Binding creation. Name references (binding usages). Activation, deactivation, reactivation of bindings (mostly due to scope rules). Binding destruction Object destruction.

Definitions Binding Lifetime: Period of time between creation and destruction of a binding. Object lifetime: Period between creation and destruction of an object. Binding lifetime usually shorter than object lifetime.

Example: Passing a Variable by Reference. main() { int n=3; // object n exists f(&n); // throughout, but... } void f(int * p) { *p = 4; // binding of p is temporary }

Binding Destruction Can Be Trouble Example: (classic no-no in C) int *f() { int p; return(&p); // binding of p is destroyed, // but object (address) stills // exists. }

Binding Lifetime Can Be Longer Than Object Lifetime Example (in C): char *p = malloc(4); strcpy(p, "abc"); free(p); // object gone, but // binding of p, to a // useless address, lives on. strcpy(p, "abc"); // Bad things can happen. Called a dangling reference: binding of a name to an object that no longer exists.

Storage Allocation Mechanisms Three main storage allocation mechanisms: 1.Static objects: Retain absolute address throughout. Examples: global variables, literal constants: "abc", 3.

Storage Allocation Mechanisms (cont’d) 2.Stack objects: Addresses relative to a stack (segment) base, usually in conjunction with fcn/proc calls. 3.Heap objects. Allocated and deallocated at programmer's discretion.

Static Space Allocation Special case: No recursion. Original Fortran, most BASICs. Variables local to procedures allocated statically, not on a stack. Procedures can share their local variables ! No more since Fortran 90.

Stack-Based Space Allocation Necessary if recursion is allowed. Each instance of an active procedure occupies one activation record (or frame) on the stack. Frame organization varies by language and implementation.

General Scheme int g; main() {A();} fcn A() bp: Base pointer. {A(); B();} For global references. proc B() fp: Frame pointer. {C();} For local references. proc C() sp: Stack pointer. {} Top of stack.

Example: (see diagram) int g=2; // g: global address 0 main() { int m=1; // m: local address 0 print(A(m)); // return address 1 } int A(int p) { // p: local address 1 int a; // a: local address 3 if p=1 return 1+A(2); // return address 2 else return B(p+1); // return address 3 } int B(int q) { // q: local address 1 int b=4; // b: local address 3 print(q+b+g); // situation depicted HERE }

Heap-Based Allocation Heap: Memory market. Memory region where memory blocks can be bought and sold (allocated and deallocated). Many strategies for managing the heap.

Heap-Based Allocation (cont’d) Main problem: fragmentation. After many allocations and deallocations, many small free blocks scattered and intermingled with used blocks. Heap Allocation request

Heap-Based Allocation (cont’d) Internal fragmentation: Allocate larger block than needed. Space wasted. External fragmentation: Can't handle a request for a large block. Plenty of free space, but no large blocks available. Need compaction, expensive. Often use a linked list of free blocks. First fit strategy: allocate first block that suffices. More efficient, but more fragmentation.

Heap-Based Allocation (cont’d) Best fit strategy: allocate smallest block that suffices. Less efficient, less fragmentation. Maintain "pools" of blocks, of various sizes. "Buddy system": blocks of size 2 k. Allocate blocks of nearest power of two. If no blocks available, split up one of size 2 k+1. When freed later, "buddy it" back, if possible.

Heap-Based Allocation (cont’d) Fibonacci heap: Use block sizes that increase as Fibonacci numbers do: f(n)=f(n-1)+f(n-2) instead of doubling. Allocation is usually explicit in PL's: malloc, new.

Heap Deallocation Implicit: Garbage Collection (Java). Automatic, but expensive (getting better). Explicit: free (C, C++), dispose (Pascal). Risky. Very costly errors, memory leaks, but efficient.

Name Binding and Object Lifetimes Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture 10