CSCI 3136Principles of Programming Languages

Names, Scopes, and Bindings - 1

Summer 2013Faculty of Computer Science

Dalhousie University

1 / 87

Name

A name is a mnemonic character string representing somethingelse:

For example:

• x,sin,f,prog1,null? are names

• 1,2,3, ‘‘test’’ are not names

• +, <=, . . . may be names, if they are not built-in operators

2 / 87

Name

A name is a mnemonic character string representing somethingelse:For example:

• x,sin,f,prog1,null? are names

• 1,2,3, ‘‘test’’ are not names

• +, <=, . . . may be names, if they are not built-in operators

3 / 87

Name

A name is a mnemonic character string representing somethingelse:For example:

• x,sin,f,prog1,null? are names

• 1,2,3, ‘‘test’’ are not names

• +, <=, . . . may be names, if they are not built-in operators

4 / 87

Name

A name is a mnemonic character string representing somethingelse:For example:

• x,sin,f,prog1,null? are names

• 1,2,3, ‘‘test’’ are not names

• +, <=, . . . may be names, if they are not built-in operators

5 / 87

Binding

A binding is an association between two entities:

For example:

• Name and a memory location (for variables)

• Name and a function

Typically a binding is between a name and the object it refers to.

A referencing environment is a complete set of bindings active at acertain point in a program.

6 / 87

Binding

A binding is an association between two entities:For example:

• Name and a memory location (for variables)

• Name and a function

Typically a binding is between a name and the object it refers to.

A referencing environment is a complete set of bindings active at acertain point in a program.

7 / 87

Binding

A binding is an association between two entities:For example:

• Name and a memory location (for variables)

• Name and a function

Typically a binding is between a name and the object it refers to.

A referencing environment is a complete set of bindings active at acertain point in a program.

8 / 87

Binding

A binding is an association between two entities:For example:

• Name and a memory location (for variables)

• Name and a function

Typically a binding is between a name and the object it refers to.

A referencing environment is a complete set of bindings active at acertain point in a program.

9 / 87

Binding

A binding is an association between two entities:For example:

• Name and a memory location (for variables)

• Name and a function

Typically a binding is between a name and the object it refers to.

A referencing environment is a complete set of bindings active at acertain point in a program.

10 / 87

Scope

• Scope of a bindingis the region of a program, or time interval(s) in the program’sexecution during which the binding is active.

• Scopeis a maximal region of the program where no bindings aredestroyed (e.g., body of a procedure).

11 / 87

Scope

• Scope of a bindingis the region of a program, or time interval(s) in the program’sexecution during which the binding is active.

• Scopeis a maximal region of the program where no bindings aredestroyed (e.g., body of a procedure).

12 / 87

Scope

• Scope of a bindingis the region of a program, or time interval(s) in the program’sexecution during which the binding is active.

• Scopeis a maximal region of the program where no bindings aredestroyed (e.g., body of a procedure).

13 / 87

Binding Times

Compile time

• Mapping of high-level language constructs to machine code

• Layout of static data in memory

Link time

• Resolve references between separately compiled modules

Load time

• Assign machine addresses to static data

Run time

• Binding of values to variables

• Allocate local variables of procedures on the stack

• Allocate dynamic data and assign to variables

14 / 87

Binding Times

Compile time

• Mapping of high-level language constructs to machine code

• Layout of static data in memory

Link time

• Resolve references between separately compiled modules

Load time

• Assign machine addresses to static data

Run time

• Binding of values to variables

• Allocate local variables of procedures on the stack

• Allocate dynamic data and assign to variables

15 / 87

Binding Times

Compile time

• Mapping of high-level language constructs to machine code

• Layout of static data in memory

Link time

• Resolve references between separately compiled modules

Load time

• Assign machine addresses to static data

Run time

• Binding of values to variables

• Allocate local variables of procedures on the stack

• Allocate dynamic data and assign to variables

16 / 87

Binding Times

Compile time

• Mapping of high-level language constructs to machine code

• Layout of static data in memory

Link time

• Resolve references between separately compiled modules

Load time

• Assign machine addresses to static data

Run time

• Binding of values to variables

• Allocate local variables of procedures on the stack

• Allocate dynamic data and assign to variables

17 / 87

Importance of Binding Time

Early binding

• Faster code

• Typical in compiled languages

Late binding

• Greater flexibility

• Typical in interpreted languages

18 / 87

Importance of Binding Time

Early binding

• Faster code

• Typical in compiled languages

Late binding

• Greater flexibility

• Typical in interpreted languages

19 / 87

Object and Binding Lifetime

Object lifetime

• Period between the creation and destruction of an object

• Example:

− time between creation and destruction of a dynamicallyallocated variable in C++ using new and delete

− pushing and popping a stack frame

Binding lifetime

• Period between the creation and destruction of the binding(name-to-object association)

Two common mistakes

• Dangling reference: no object for a binding (e.g., a pointerrefers to an object that has already been deleted)

• Memory leak: no binding for an object (preventing the objectfrom being deallocated)

20 / 87

Object and Binding Lifetime

Object lifetime

• Period between the creation and destruction of an object

• Example:

− time between creation and destruction of a dynamicallyallocated variable in C++ using new and delete

− pushing and popping a stack frame

Binding lifetime

• Period between the creation and destruction of the binding(name-to-object association)

Two common mistakes

• Dangling reference: no object for a binding (e.g., a pointerrefers to an object that has already been deleted)

• Memory leak: no binding for an object (preventing the objectfrom being deallocated)

21 / 87

Object and Binding Lifetime

Object lifetime

• Period between the creation and destruction of an object

• Example:

− time between creation and destruction of a dynamicallyallocated variable in C++ using new and delete

− pushing and popping a stack frame

Binding lifetime

• Period between the creation and destruction of the binding(name-to-object association)

Two common mistakes

• Dangling reference: no object for a binding (e.g., a pointerrefers to an object that has already been deleted)

• Memory leak: no binding for an object (preventing the objectfrom being deallocated)

22 / 87

Storage Allocation

An object’s lifetime corresponds to the mechanism used to managethe space where the object resides.

Static object

• Object stored at a fixed absolute address

• Object’s lifetime spans the whole execution of the program

Object on stack

• Object allocated on stack in connection with a subroutine call

• Object’s lifetime spans period between invocation of thesubroutine and return from the subroutine

Object on heap

• Object stored on heap• Object created/destroyed at arbitrary times

− Explicitly by programmer or− Implicitly by garbage collector

23 / 87

Storage Allocation

An object’s lifetime corresponds to the mechanism used to managethe space where the object resides.Static object

• Object stored at a fixed absolute address

• Object’s lifetime spans the whole execution of the program

Object on stack

• Object allocated on stack in connection with a subroutine call

• Object’s lifetime spans period between invocation of thesubroutine and return from the subroutine

Object on heap

• Object stored on heap• Object created/destroyed at arbitrary times

− Explicitly by programmer or− Implicitly by garbage collector

24 / 87

Storage Allocation

An object’s lifetime corresponds to the mechanism used to managethe space where the object resides.Static object

• Object stored at a fixed absolute address

• Object’s lifetime spans the whole execution of the program

Object on stack

• Object allocated on stack in connection with a subroutine call

• Object’s lifetime spans period between invocation of thesubroutine and return from the subroutine

Object on heap

• Object stored on heap• Object created/destroyed at arbitrary times

− Explicitly by programmer or− Implicitly by garbage collector

25 / 87

Storage Allocation

An object’s lifetime corresponds to the mechanism used to managethe space where the object resides.Static object

• Object stored at a fixed absolute address

• Object’s lifetime spans the whole execution of the program

Object on stack

• Object allocated on stack in connection with a subroutine call

• Object’s lifetime spans period between invocation of thesubroutine and return from the subroutine

Object on heap

• Object stored on heap• Object created/destroyed at arbitrary times

− Explicitly by programmer or− Implicitly by garbage collector

26 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

27 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

28 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

29 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

30 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

31 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

32 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

33 / 87

Example: Object Creation and Destruction in C++

• Local objects are local to functions and blocks and exist whilethe execution is inside the function or block.

• Heap objects are allocated/deallocated using new/delete.(free-store objects)

• Non-static member objects of a parent object exist while theparent object exists.

• Array elements exist while the array exists.

• Local static objects of functions/blocks exist after the firstinvocation of the function until termination.

• Global, namespace, class static objects exist while theprogram runs.

• Temporary objects in expressions exist during the evaluationof the expression.

34 / 87

Static Objects

• Global variables

• Variables local to subroutines, but retain their value betweeninvocations

• Constant literals

• Tables for run-time support: e.g., debugging, type checking,etc.

• Space for subroutines, including local variables in languagesthat do not support recursion (e.g., early versions ofFORTRAN)

35 / 87

Static Objects

• Global variables

• Variables local to subroutines, but retain their value betweeninvocations

• Constant literals

• Tables for run-time support: e.g., debugging, type checking,etc.

• Space for subroutines, including local variables in languagesthat do not support recursion (e.g., early versions ofFORTRAN)

36 / 87

Static Objects

• Global variables

• Variables local to subroutines, but retain their value betweeninvocations

• Constant literals

• Tables for run-time support: e.g., debugging, type checking,etc.

• Space for subroutines, including local variables in languagesthat do not support recursion (e.g., early versions ofFORTRAN)

37 / 87

Static Objects

• Global variables

• Variables local to subroutines, but retain their value betweeninvocations

• Constant literals

• Tables for run-time support: e.g., debugging, type checking,etc.

• Space for subroutines, including local variables in languagesthat do not support recursion (e.g., early versions ofFORTRAN)

38 / 87

Static Objects

• Global variables

• Variables local to subroutines, but retain their value betweeninvocations

• Constant literals

• Tables for run-time support: e.g., debugging, type checking,etc.

• Space for subroutines, including local variables in languagesthat do not support recursion (e.g., early versions ofFORTRAN)

39 / 87

Static Objects

• Global variables

• Variables local to subroutines, but retain their value betweeninvocations

• Constant literals

• Tables for run-time support: e.g., debugging, type checking,etc.

• Space for subroutines, including local variables in languagesthat do not support recursion (e.g., early versions ofFORTRAN)

40 / 87

Stack-Based Allocation

The stack is used to allocate space for subroutines in languagesthat permit recursion.

The stack frame (activation record) contains

• Arguments and local variables of the subroutine,

• The return value(s) of the subroutine,

• The return address, etc.

The subroutine calling sequence maintains the stack:

• Before call, the caller pushes arguments and return addressonto the stack.

• After being called (prologue), the subroutine (callee) initializeslocal variables, etc.

• Before returning (epilogue), the subroutine cleans up localdata.

• After the call returns, the caller retrieves return value(s) andrestores the stack to its state before the call.

41 / 87

Stack-Based Allocation

The stack is used to allocate space for subroutines in languagesthat permit recursion.The stack frame (activation record) contains

• Arguments and local variables of the subroutine,

• The return value(s) of the subroutine,

• The return address, etc.

The subroutine calling sequence maintains the stack:

• Before call, the caller pushes arguments and return addressonto the stack.

• After being called (prologue), the subroutine (callee) initializeslocal variables, etc.

• Before returning (epilogue), the subroutine cleans up localdata.

• After the call returns, the caller retrieves return value(s) andrestores the stack to its state before the call.

42 / 87

Stack-Based Allocation

The stack is used to allocate space for subroutines in languagesthat permit recursion.The stack frame (activation record) contains

• Arguments and local variables of the subroutine,

• The return value(s) of the subroutine,

• The return address, etc.

The subroutine calling sequence maintains the stack:

• Before call, the caller pushes arguments and return addressonto the stack.

• After being called (prologue), the subroutine (callee) initializeslocal variables, etc.

• Before returning (epilogue), the subroutine cleans up localdata.

• After the call returns, the caller retrieves return value(s) andrestores the stack to its state before the call.

43 / 87

Stack Frame (Activation Record)

Compiler determines

• Frame pointer: a register pointing to a known location withinthe current stack frame

• Offsets from the frame pointer specifying the location ofobjects in the stack frame

The absolute size of the stack frame may not be known at compiletime (e.g., variable-size arrays allocated on the stack).Stack pointer

• Register pointing to the first unused location on the stack(used as the starting position for the next stack frame)

Specified at runtime

• The absolute location of the stack frame in memory (on thestack)

• The size of the stack frame

44 / 87

Stack Frame (Activation Record)

Compiler determines

• Frame pointer: a register pointing to a known location withinthe current stack frame

• Offsets from the frame pointer specifying the location ofobjects in the stack frame

The absolute size of the stack frame may not be known at compiletime (e.g., variable-size arrays allocated on the stack).Stack pointer

• Register pointing to the first unused location on the stack(used as the starting position for the next stack frame)

Specified at runtime

• The absolute location of the stack frame in memory (on thestack)

• The size of the stack frame

45 / 87

Stack Frame (Activation Record)

Compiler determines

• Frame pointer: a register pointing to a known location withinthe current stack frame

• Offsets from the frame pointer specifying the location ofobjects in the stack frame

The absolute size of the stack frame may not be known at compiletime (e.g., variable-size arrays allocated on the stack).

Stack pointer

• Register pointing to the first unused location on the stack(used as the starting position for the next stack frame)

Specified at runtime

• The absolute location of the stack frame in memory (on thestack)

• The size of the stack frame

46 / 87

Stack Frame (Activation Record)

Compiler determines

• Frame pointer: a register pointing to a known location withinthe current stack frame

• Offsets from the frame pointer specifying the location ofobjects in the stack frame

The absolute size of the stack frame may not be known at compiletime (e.g., variable-size arrays allocated on the stack).Stack pointer

• Register pointing to the first unused location on the stack(used as the starting position for the next stack frame)

Specified at runtime

• The absolute location of the stack frame in memory (on thestack)

• The size of the stack frame

47 / 87

Stack Frame (Activation Record)

Compiler determines

• Frame pointer: a register pointing to a known location withinthe current stack frame

• Offsets from the frame pointer specifying the location ofobjects in the stack frame

The absolute size of the stack frame may not be known at compiletime (e.g., variable-size arrays allocated on the stack).Stack pointer

• Register pointing to the first unused location on the stack(used as the starting position for the next stack frame)

Specified at runtime

• The absolute location of the stack frame in memory (on thestack)

• The size of the stack frame48 / 87

Stack Frame Before, During and After Subroutine Call

49 / 87

Heap-Based Allocation

The heap is a region of memory where subblocks can be allocatedand deallocated at arbitrary times and in arbitrary order.

Heap management

• Free list: linked list of free blocks (of memory)

• The allocation algorithm searches for a block of adequate sizeto accommodate the allocation request.

50 / 87

Heap-Based Allocation

The heap is a region of memory where subblocks can be allocatedand deallocated at arbitrary times and in arbitrary order.

Heap management

• Free list: linked list of free blocks (of memory)

• The allocation algorithm searches for a block of adequate sizeto accommodate the allocation request.

51 / 87

First-Fit and Best-Fit Allocation

• First fit: grab first block that is large enough

• Best fit: grab smallest block that is large enough

52 / 87

Heap Fragmentation Problem

Internal fragmentation

• part of a block is unused

External fragmentation

• unused space consists of many small blocks

• although total free space may exceed allocation request,individual free blocks may be too small

Is there less external fragmentation with “best fit” or “first fit”?

Neither best-fit nor first-fit is guaranteed to minimize externalfragmentation. Which strategy is better depends on the sizedistribution of the allocation requests.

53 / 87

Heap Fragmentation Problem

Internal fragmentation

• part of a block is unused

External fragmentation

• unused space consists of many small blocks

• although total free space may exceed allocation request,individual free blocks may be too small

Is there less external fragmentation with “best fit” or “first fit”?

Neither best-fit nor first-fit is guaranteed to minimize externalfragmentation. Which strategy is better depends on the sizedistribution of the allocation requests.

54 / 87

Heap Fragmentation Problem

Internal fragmentation

• part of a block is unused

External fragmentation

• unused space consists of many small blocks

• although total free space may exceed allocation request,individual free blocks may be too small

Is there less external fragmentation with “best fit” or “first fit”?

Neither best-fit nor first-fit is guaranteed to minimize externalfragmentation. Which strategy is better depends on the sizedistribution of the allocation requests.

55 / 87

Heap Fragmentation Problem

Internal fragmentation

• part of a block is unused

External fragmentation

• unused space consists of many small blocks

• although total free space may exceed allocation request,individual free blocks may be too small

Is there less external fragmentation with “best fit” or “first fit”?

Neither best-fit nor first-fit is guaranteed to minimize externalfragmentation. Which strategy is better depends on the sizedistribution of the allocation requests.

56 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

57 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

58 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

59 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

60 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

61 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

62 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

63 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

64 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

65 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

66 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

67 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

68 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

69 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

70 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

71 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

72 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

73 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

74 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

75 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

76 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation

77 / 87

Cost of Allocation on a HeapSingle free list

• linear cost in the number of free blocks

Buddy system

• Block sizes are powers of 2

• Separate free list for blocks of size2k, for each k

• If block of size 2k is unavailable,split block of size 2k+1

• If block of size 2k is deallocatedand its buddy is free, merge theminto a block of size 2k+1

• Worst-case cost: log(memory size)

Fibonacci heap

• Block sizes that are Fibonacci #:1, 1, 2, 3, 5, 8, 13, 21, 34, . . .

• Less fragmentation78 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

79 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

80 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

81 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

82 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon

− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

83 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

84 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

85 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

86 / 87

Deallocation on a Heap

Explicit deallocation by programmer

• Used in Pascal, C, C++, . . .

• Efficient

• May lead to bugs that are difficult to find:

− Dangling pointers/references from deallocating too soon− Memory leaks from not deallocating

Automatic deallocation by garbage collector

• Used in Java, functional and logic programming languages, . . .

• Can add significant runtime overhead

• Safer

87 / 87