Name Binding and Object Lifetimes

1
Name Binding and Object Lifetimes
Programming Language Concepts Lecture 07

• Prepared by
• Manuel E. Bermúdez, Ph.D.
• Associate Professor
• University of Florida

2
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.

3
Name Binding

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

4
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.

5
Binding Can Occur at Various Times (contd)

• Program writing time. Names of data structures,
  modules.
• Example names of debugging flags for C
  preprocessor
• define DEBUGGING 1
• ...
• if DEBUGGING
• printf( ... )
• endif

6
Binding Can Occur at Various Times (contd)

• 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.

7
Binding Can Occur at Various Times (contd)

• 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.

8
Terminology

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

9
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.

10
Examples (contd)

• Late binding most interpreted languages, e.g.
  RPAL, BASIC, perl, shell script languages,
  Smalltalk.
• More analysis done at run time, less efficient.

11
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.

12
(No Transcript)
13
Scope Rules

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

14
Examples

• const x7
• Binds x to (7,type integer).
• var xinteger
• 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)

15
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.

16
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.

17
Example Passing a Variable by Reference.

• main()
• int n3 // object n exists
• f(n) // throughout, but ...
• void f(int p)
• p 4
• // binding of p is temporary

18
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.

19
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.

20
Storage Allocation Mechanisms

• Three main storage allocation mechanisms
• Static objects
• Retain absolute address throughout.
• Examples global variables, literal constants
  "abc", 3.

21
Storage Allocation Mechanisms (contd)

• Stack objects
• Addresses relative to a stack (segment) base,
  usually in conjunction with fcn/proc calls.
• Heap objects. Allocated and deallocated at
  programmer's discretion.

22
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.

23
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.

24
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.

25
(No Transcript)
26
Example (see diagram)

• int g2 // g global address 0
• main()
• int m1 // 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 p1
• return 1A(2) // return address 2
• else
• return B(p1) // return address 3
• int B(int q) // q local address 1
• int b4 // b local address 3
• print(qbg) // situation depicted HERE

27
(No Transcript)
28
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.

29
Heap-Based Allocation (contd)

• Main problem fragmentation.
• After many allocations and deallocations, many
  small free blocks scattered and intermingled with
  used blocks.

Heap
Allocation request
30
Heap-Based Allocation (contd)

• 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.

31
Heap-Based Allocation (contd)

• Best fit strategy allocate smallest block that
  suffices. Less efficient, less fragmentation.
• Maintain "pools" of blocks, of various sizes.
• "Buddy system" blocks of size 2k. Allocate
  blocks of nearest power of two. If no blocks
  available, split up one of size 2k1. When freed
  later, "buddy it" back, if possible.

32
Heap-Based Allocation (contd)

• 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.

33
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.

34
Name Binding and Object Lifetimes
Programming Language Principles Lecture 07

• Prepared by
• Manuel E. Bermúdez, Ph.D.
• Associate Professor
• University of Florida