Post on 04-Dec-2020
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