Last week, we had begun talking about Chapter 3 Names, Scopes, and Bindings.
We said names are usually identifiers (alphanumeric tokens) that allow us to refer to variables, constants, operations, types, and so on without having to refer to low level concepts like addresses.
We said the association of a name to a thing is called a binding.
We then looked at binding time, binding lifetime versus object lifetime, and then started talking about storage allocation.
We said there are three main kinds of storage allocation: Static - objects are given an absolute address, Stack - objects are allocated and deallocated in last-in, first--out order, usually in conjunction with subroutine calls and returns, and Heap - objects may be allocated and deallocated at arbitrary times.
We begin today by looking at these three kinds of allocation in more detail.
Static Allocation
In a typical program several kinds of objects might be statically allocated:
Global variables
Program functions are usually allocated statically. In C, function pointers can be used to refer to where a program's code is stored.
Numeric and string valued literals are usually statically allocated. I.e., 14.7 or "hello world".
Runtime support tables used by support routines for debugging, dynamic type checking, garbage collection, exception handling, etc.
Older programming languages such as Fortran before Fortran 90 that did not support recursion, used static allocation for local variables. Most modern languages can still use the keyword static or own in a function to cause static allocation of a local variable.
Statically allocated objects whose value should not change during program execution (constants and certain run time tables) are often allocated in protected read-only memory, so that attempting to write to them will cause a processor interrupt and a run-time error.
Stack Allocation
If a language permits recursion, then stack based allocation of local variables is typically done.
The figure above illustrates how this process works.
Each instance of a subroutine at run time has its own frame (also called an activation record) on the stack, containing arguments and return values, local variables, temporaries, and bookkeeping information.
Temporaries are used to stored intermediate values produced usually when evaluating expression. For example a*x*x + c, might use temporaries for the storage of x*x and a*x*x.
Bookkeeping info typically includes the subroutines return address, a reference to the stack frame of the caller (aka a dynamic link), saved values of the registers needed by both caller and callee, etc
The stack is maintained by a machine code routines that are run by the caller immediately before and after the call (calling sequence code) and by prologue (at start of subroutine) and epilogue (at the end of subroutine) code of the callee.
Although the stack frame location, cannot be predicted at compile time, offsets from the start of frame pointer (usually stored in frame pointer register) can be determined statically.
Heap-Based Allocation
A heap is a region of storage (not to be confused with heap data structure) in which subblocks can be allocated and deallocated at arbitrary times.
Heaps are used for objects such as character strings, struct/class objects, lists, sets, etc whose size may change as a result of an assignment or update operation.
Heaps are typically optimized to minimize time to manage, and minimize space fragmentation.
Fragmentation can be either internal when a larger block of space is allocated than needed, or external when the blocks assigned to active objects are scattered through the heap, so that even though there might be enough memory in the whole heap for a memory request, there is not enough contiguous memory to satisfy it (figure above).
Heap Storage Management
The storage management algorithm for a heap often uses a single-linked list called the free list of blocks not currently in use.
Initially, the free list consists of a single block comprising the entire heap
On an allocation request, the algorithm searches the list for a block of appropriate size.
Strategies for this search may be first fit (first block that works) or best fit (smallest block that works).
If the block is larger than needed it may be split into a smaller block and the unused portion being added back to the free list.
When a block is deallocated and returned to the free space list, a check is done to see whether either or both adjacent free blocks can be coalesced with it.
The cost of allocation using the above strategy is linear in the number of free blocks.
To reduce this to a constant, some algorithms maintain a separate list for blocks of different sizes.
Each request is rounded up to the next standard size and allocated from the appropriate list.
The division into pools can be either static or dynamic.
Dynamic Storage Pools
The two most common approaches to dynamic heap storage pools are the buddy system and Fibonnaci heaps.
We'll describe the buddy system as it is simpler.
The basic idea of the buddy system is the heap blocks will always be a power of two (`2^k`).
The initial heap has pools according to the binary representation of its size. I.e., if it size in binary is `sum_j a_j 2^j` the if `a_j` is 1 it will have a pool of size `2^j`.
For each `2^j` less than the size of the heap we have a free list of that power (may be empty list).
If a block of size `2^k` is needed, but none is available, a block of size `2^{k+1}` is split (if no block of size `2^{k+1}` is available we look at those of size `2^{k+2}`, etc).
One half of the split block is used for the allocation, the other have is added to the `2^k` free list.
If a block is deallocated it is coalesced with its buddy if it is still free.
Handling External Fragmentation
Because of external fragmentation, the ability of a heap to satisfy requests tends to degrade with time.
To combat this, periodically, we need to compact the heap to group together in contiguous memory the free space lists.
One difficulty with this is that it means we might also have to adjust all outstanding references to allocated blocks that need to be moved by this process.
Garbage Collection
Allocation of heap-based objects may be triggered by: malloc, instantiating object, appending to a list, etc.
Deallocation is also explicit in some languages (C, C++, Objective-C, Rust).
Other languages (Java, C#) deallocate object implicitly when it is not longer possible to reach them from a program variable.
For such language, a runtime garbage collection mechanism is used to periodically reclaim unreachable objects.
Garbage collection makes it easier to avoid problem like dangling references and memory leaks.
On the other, garbage collection is often tricky to implement.
Some domains for example programs controlling a nuclear power plant have precise tolerances on how long different code regions should take (i.e., that value repeatability in run time for the same code). In these situations garbage collection or even heap compaction can cause problems. (Why Java is not permitted for certain kinds of government projects.)
Quiz
Which of the following statements is true?
It is impossible to have two leftmost derivations of the same string.
Yacc is a tool to make it easier to create LR(1) parsers in C.
The terms binding lifetime and object lifetime are synonyms.
Scope Rules
The textual region of the program in which a binding is active is its scope.
In many language, this scope is determined statically at compile time.
For example, in C, a new scope is introduced when a subroutine is entered.
This involves creating bindings for local objects and deactivating bindings for hidden global objects.
As we can look at a C program and know which names refer to which objects at which point in the program based on purely textual rules, we say C is statically scoped.
If the active bindings depend on the flow of execution at run time (APL, Snobol, TCL, old Lisp), we say a language is dynamically scoped.
The set of active bindings at a given point in a program's execution is called the current referencing environment.
This set of bindings is determined by static or dynamic scope rules.
It can also depend on binding rules which determine when a reference to a subroutine S is stored in a variable (for example a function pointer) is passed to another subroutine, we need to choose the referencing environment that S has access to.
Two possibilities for this are deep binding, the referencing environment is from when S was created, and shallow binding, the referencing environment is when S is used.
Let's look at kinds of scoping in more detail.
Static Scoping
In a typical statically scoped language, the "current binding" for a given name is found by matching the declaration whose block most closely surrounds a given point in the program.
There are several variations on this that have been considered...
In early version of BASIC (Kenemy, Kurtz 1964), there was only a single, global scope. Each name was a letter followed by a digit. Variables are not explicitly declared, but are implicit declared when first used.
In Fortran 77 and earlier, there is a distinction between global and local variables. A global variable is visible everywhere, a local variable is visible to the subroutine in which it appears. Variable declaration is optional, if a variable is not declared, its scope is local to the subroutine in which it is used, and it is assumed to be of type integer if its names begins with I-N and real otherwise. Semantically, the lifetime of a local variable encompasses a single execution of the variable's subroutine. This can be overridden by save-ing variable. A save-ed (static, own) variable has lifetime the duration of the program. Below is a C function illustrating static variables
/*
Place into *s a new name beginning with the letter 'L' and
continuing with the ASCII representation of a unique integer.
Parameter s is assumed to point to space large enough to
hold any such name; for the short int's used here, 7 characters suffice.
*/
void label_name (char *s) {
static short int n; /* C guarantees that static locals are
initialized to zero */
sprintf (s, "L%d\0", ++n); /* "print" formatted output to s */
}
Each time it is called the string pointer will receive a different string beginning with L.
