Lecture 12: Arrays, Pointers, Recursive Types, &

Garbage Collection
COMP 524 Programming Language Concepts
Aaron Block
February 27, 2007

Based on notes by N. Fisher, F. Hernandez-Campos, and D. Stotts

The University of North Carolina at Chapel Hill

Goals

•Discuss Arrays, Pointers, Recursive Types, and Garbage

Collection

The University of North Carolina at Chapel Hill 2

Arrays

•Arrays are usually stored in contiguous locations

row-major
order

The University of North Carolina at Chapel Hill 3

Arrays

•Arrays are usually stored in contiguous locations

Column-
major order

The University of North Carolina at Chapel Hill 4

 Arrays
char days[][10] = { char *days[] = {
“sun”, “mon”, “tue”, “sun”, “mon”, “tue”,
“wed”, “thu”, “fri”, “wed”, “thu”, “fri”,
“sat” “sat”
}; };

S U N S U N M
M O N O N T U
T U E E W E D
W E D T H U
T H U F R I S
F R I A T
S A T
The University of North Carolina at Chapel Hill 5
Arrays: Address Calculations
A: array [L1..U1] of array [L2..U2] of array [l3..U3]
of element_type

L3

j L1
L2
k

The University of North Carolina at Chapel Hill 6

Arrays: Address Calculations
A: array [L1..U1] of array [L2..U2] of array [l3..U3]
of element_type

L3

j L1
S3 = size of element
S2 = (U3-L3+1) x S3 L2
k S1 = (U2 - L2 +1) x S2
Address of A[i,j,k]
Address
i of A + (i-L1)xS1 + (j-L2)xS2 + (k-L3)xS3

The University of North Carolina at Chapel Hill 7

 Arrays: Address Calculations
A: array [L1..U1] of array [L2..U2] of array [l3..U3]
of element_type

L3

j L1
Optimized
(i x S1) + (j x S2) + (k x S3) + address A - L2
[(L1
k x S1) + (L2 x S2) + (L3 x S3)].
the phrase [(L1 x S1) + (L2 x S2) + (L3 x S3)] can be
i determined at compile-time

The University of North Carolina at Chapel Hill 8

Heap-based Allocation

•The heap is a region of storage in which sub-blocks can

be allocated and deallocated.

The University of North Carolina at Chapel Hill 9

Issues with Heap Allocation

•Pointers
• Used in value model of variables
• Not necessary for reference model

•Dangling References
•Garbage Collection

The University of North Carolina at Chapel Hill 10

Pointers

•Pointers serve two purposes:

• Efficient (and sometimes intuitive) access to elaborated objets
(as in C)
• Dynamic creation of linked data structures, in conjunction with
a heap storage manger.

•Several Languages (e.g., Pascal) restrict pointers to

accessing things in the heap
•Pointers are used with a value model of variables
• They aren’t needed with a reference model (already implicit)

The University of North Carolina at Chapel Hill 11

C Pointers and Arrays

•C Pointers and array

int *a == int a[]

int **a ==int *a[]

The University of North Carolina at Chapel Hill 12

C Pointers and Arrays

•But equivalencies don’t always hold

• Specifically, a deceleration allocates an array if it specifies a
size for the first dimension
• otherwise it allocates a pointer

int **a, int *a[] // Pointer to pointer to int

int *a[n] //n-element array of row pointers
int a[n][m] // 2-D array

The University of North Carolina at Chapel Hill 13

Recursive Types (now with Pointers!): Binary Tree

struct chr_tree{
struct chr_tree *l, *r; C
char var;
}

type chr_tree;
Ada
type chr_tree_ptr is access chr_tree;
type chr_tree is record
left,right:chr_tree_ptr;
val:characte;
end record;

The University of North Carolina at Chapel Hill 14

Binary Tree with Explicit Pointers

R C

X Y

Z W

The University of North Carolina at Chapel Hill 15

Binary Tree in Reference Model

C C C Lisp
A R

C C C C C C

A X A Y

C C C

A Z
C C C

A W
‘(#\R (#\X () ()) (#\Y (#\Z () ()) (#\W () ())))

The University of North Carolina at Chapel Hill

Lists

•A list is defined recursively as either the empty list or a

pair consisting of an object (which may be either a list or
an atom) and another (shorter) list
• Lists are ideally suited to programming in functional and logical
languages
• In Lisp, in fact, a program is a list, and can extend itself at run time
by constructing a list and executing it.

• Lists can also be used in imperative programs

• We’ll see more in the future

The University of North Carolina at Chapel Hill 17

Problems with Explicit Reclamation

•Explicit reclamation of heap objects is problematic

• The programmer may forget to deallocate some objects
• Causing memory leaks
• For example, in the previous example, the programmer may forget
to include the delete statement

• References to deallocated objets may not be reset

• Creating dangling references

ptr1 ptr2

The University of North Carolina at Chapel Hill 18

Problems with Explicit Reclamation

•Explicit reclamation of heap objects is problematic

• The programmer may forget to deallocate some objects
• Causing memory leaks
• For example, in the previous example, the programmer may forget
to include the delete statement

• References to deallocated objets may not be reset

• Creating dangling references

ptr2

The University of North Carolina at Chapel Hill 19

Dealing with Dangling References

•Tombstones: Use an intermediary device

•Lock and Keys: Use a universal key.

The University of North Carolina at Chapel Hill 20

 Tombstones

new(ptr1); ptr1

ptr1
ptr2 := ptr1;

ptr2

ptr1
delete(ptr1);

ptr2

The University of North Carolina at Chapel Hill 21

 Locks and Keys

new(ptr1); ptr1:135942 135942

ptr1:135942
135942
ptr2 := ptr1;
ptr2:135942

ptr1:135942 0
delete(ptr1);
ptr2:135942

The University of North Carolina at Chapel Hill

Garbage Collection

•Automatic reclamation of the space used by objects

that are no longer useful:
• Developed for functional languages
• Essential in this programming paradigm. Why?

• Getting more and more popular in imperative languages

• Java, C#, Python

•Generally slower than manual reclamation, but it

eliminates a very frequent programming error

The University of North Carolina at Chapel Hill 23

Garbage Collection: Techniques

•When is an object no longer useful?

•There are several garbage collection techniques that
answer this question in a different manner
• Reference counting
• Mark-and-sweep collection

The University of North Carolina at Chapel Hill 24

Reference Counting

•Each object has an associated reference counter

stooges 2 “larry” 1 “moe”

Stack Heap 1 “curly”

•Keeps reference counter up to date, and recursively

deallocates objects when the counter is zero

The University of North Carolina at Chapel Hill 25

Reference Counting: Problems

•Extra overhead of storing and updating reference

counts
•Strong Typing required
• Impossible in language like C
• It cannot be used for variant records

• It doesn’t work with circular data structures

• This is a problem with this definition of useful object as an
object with one or more references

The University of North Carolina at Chapel Hill 26

Reference Counting: Circular Data Structures

stooges 2 “larry” 1 “moe”

Stack Heap 1 “curly”

stooges 1 “larry” 1 “moe”

Stack Heap 1 “curly”

The University of North Carolina at Chapel Hill 27

Mark-and-Sweep Collection

• A better definition of useless is one that cannot be reached by

following a chain of valid pointers starting from outside the
heap.
• Mark-and-Sweep GC applies this definition

The University of North Carolina at Chapel Hill 28

Mark-And-Sweep

• Algorithm:
• Mark every block in the heap as useless
• Starting with all pointers outside the heap, recursively explore
all linked data structures
• Add every block that remain marked to the free list.
• Run whenever free space is low

The University of North Carolina at Chapel Hill 29

Mark-and-Sweep Collection: Problems

•Block must begin with an indication of its size

•A stack of depth proportional to the longest
reference chain is required
• AND! We are usually running low when running the GC

The University of North Carolina at Chapel Hill 30

Mark-and-Sweep Collection: Problems

•Block must begin with an indication of its size

•A stack of depth proportional to the longest
reference chain is required
• AND! We are usually running low when running the GC
If we use type descriptors, that indicate their
size, then we don’t need to do this.

The University of North Carolina at Chapel Hill 31

Mark-and-Sweep Collection: Problems

•Block must begin with an indication of its size

•A stack of depth proportional to the longest
reference chain is required
• AND! We are usually running low when running the GC

Possible to implement without a stack!

The University of North Carolina at Chapel Hill 32

Mark-and-Sweep Collection: Pointer Reversal

X Y

Z W

The University of North Carolina at Chapel Hill 33

Mark-and-Sweep Collection: Pointer Reversal

X Y

Z W

The University of North Carolina at Chapel Hill 34

Mark-and-Sweep Collection: Pointer Reversal

X Y

Z W

The University of North Carolina at Chapel Hill 35

Mark-and-Sweep Collection: Pointer Reversal

X Y

Z W

The University of North Carolina at Chapel Hill 36

Mark-and-Sweep Collection: Pointer Reversal

X Y

Z W

The University of North Carolina at Chapel Hill 37

Mark-and-Sweep Collection: Pointer Reversal

X Y

Z W

The University of North Carolina at Chapel Hill 38

Store-and-Copy

•Use to reduce external fragmentation

•S-C divides the available space in half and allocates

everything in that half until its full
•When that happens, copy each useful block to the
other half, clean up the remaining block, and switch
the roles of each half.

The University of North Carolina at Chapel Hill 39