1. Storage Management
Lecture 12:
Dolores Zage

2. Data Central concern for the programmer the language designer
the language implementor

3. Programmer Must design programs that use storage efficiently
problem: likely to have little direct control over storage
a program affects storage only indirectly through the use or lack of different language features
most language designers and implementers treat storage management as a machine-dependent topic -> not directly discussed in language manuals

4. Language Designer
Desire to allow one or another storage management technique
Examples: FORTRAN - no recursive subprogram note that recursive calls could be added without a change in syntax, but would require run-time stack of return points, a structure necessitating dynamic storage management (FORTRAN is static storage management)
Pascal - designed to allow stack-based storage management
LISP - allow garbage collection

5. Language Implementation
The design permits the use of certain storage management techniques
details of the mechanisms, and their representation in hardware and software are the task of the implementers
Example: LISP design may imply a free-space list and garbage collection as appropriate basis for storage management
there are several garbage-collection techniques

6. Major Run-Time Elements Requiring Storage
Programmers then to view storage management largely in terms of storage of data and translated programs
However MUCH more

7. Major Run-Time Elements Requiring Storage
Code segments for translated user programs
System run-time programs
User-defined data structures and constants
Subprogram return points
Referencing environments
Temporaries in expression evaluation
Temporaries in parameter transmission
Input-output buffers
Miscellaneous system data
Subprogram call and return operations
Data structure creation and destruction operations
Component insertion and deletion operations

8. Code segments for translated user programs
A major block of storage to store the code segments representing the translated form of the user programs, regardless of whether programs are hardware or software interpreted.
Hardware - blocks of executable machine code
Software - in some intermediate form

9. System run-time programs
Another substantial block
range from simple library routines, such as sine, cosine or print-string functions to software interpreters or translators
also routines that control run-time storage management
system programs are hardware-executable machine code regardless of the executable form of the user program

10. User-defined data structures and constants
Space for user data
for all data structures declared in or created by user programs including constants

11. Subprogram return points
Subprograms have the property that they may be invoked from different points in the program
therefore, internally generated sequence-control information, such as subprogram return points, coroutine resume points, or event notices for scheduled subprograms

12. Referencing environments
Referencing environments - identifier associations
each subprogram has a set of identifier associations available for use in referencing during its execution
may have several components: local, nonlocal, global, predefined

13. Temporaries in expression evaluation Temporaries in parameter transmission
Expression evaluation requires the use of system-defined temporary storage for the intermediate results of evaluation (expression involving a recursive function call)
when a subprogram is called a list of actual parameters must be evaluated and the resulting values stored in temporary storage until evaluation of the entire list is complete

14. Input-output buffers Miscellaneous system data
Buffers serve as temporary storage between the time of the actual physical transfer of data to or from external storage and the program-initiated I/O operations
in almost every language implementation, storage is required for various system data: tables, status information for I/O, reference counts, or garbage collection bits

15. Subprogram call and return operations
Besides data and program elements requiring storage, it is instructive to consider the various operations that may require storage to be allocated or freed.
Storage for the activation record, the local referencing environment, other data on call.
The return usually requires freeing of storage allocated during the call

16. Data structure creation and destruction operations Component insertion and deletion operations
If a language provides operations that allow new data structures to be created at arbitrary points during program execution, then these operations ordinarily require storage allocation separate from that allocated on subprogram entry (malloc/free, new/dispose)
if the language provides operations that insert or delete components (ML and LISP)

17. Hidden Storage Management
These last operations require explicit storage management
many other operations require some hidden storage management
much of this involves the allocation and freeing of temporary storage for housekeeping purposes

18. Programmer and System-Controlled Storage Management
C became very popular because it allows extensive programmer control over storage
Other languages allow the program no direct control - only implicitly through language features

19. Programmer Control Places a large burden on programmer
get garbage and dangling references
extremely difficult for the system to determine when storage may be most effectively allocated and freed - but programmer often knows precisely
may also interfere with necessary system-controlled storage management
storage management routines may be required and allow less efficient use of storage overall

20. Programmer Control
Do you provide “protection” by using a language with strong typing and effective storage management features with a corresponding decrease in performance
Do you need the performance characteristics (storage management and execution speed) with an increase in risk that the program may contain errors and failure during execution

21. Storage Management Phases
Initial - at the start of execution each piece of storage may be allocated for some use or free. (requires technique for score keeping)
Recovery - storage allocated and used that becomes available. Recovery can be simple as in repositioning the stack pointer, or very complex as in garbage collection
Compaction and reuse - storage recovered may be immediately ready for reuse or compaction may be necessary to construct large blocks of free storage from small pieces

22. Static Storage Management
Simplest form
allocation during translation remains fixed throughout execution
no run time management, so no concern for recovery and reuse
usual FORTRAN, COBOL and C also permits static data to create efficient execution
for many programs static allocation is satisfactory!

23. Stack-Based Storage Management
Simplest run-time storage management technique
free storage at the the start of execution is set up as a sequential block in memory
as storage is allocated, it is taken from the sequential locations in this stack block beginning at one end.
Storage must be freed in the reverse order of allocation so that a block of storage being freed is always at the top of the stack

24. Stack-Based Storage Management
A single stack pointer is all that is needed
Compaction occurs automatically as part of freeing storage
last-in first out scheme
Pascal
new and dispose uses heap

25. Heap Storage Management
Heap is a block of storage within which pieces are allocated and freed in some relatively unstructured manner.
Problems of allocation, recovery, compaction, and reuse may be severe
there is no single heap storage management but rather a collection of techniques
must use heap when language allows creation, destruction of data arbitrarily

26. Heap Storage Management
Two categories - fixed or variable size
fixed - makes things much easier - everything divided equally
linked list of free-space
to allocate - first element on the free-space is removed from the list and a pointer to its is returned
when freed - add at the head of free-space

27. Recovery
Return of newly freed storage to the free-space list is simple, provided such storage may be identified and recovered
Three techniques:
Explicit return by programmer or system
reference counts
garbage collection - allow garbage to collect until free list is exhausted then do something

28. Explicit Return Simplest recovery technique
natural recovery technique for the heap
problems: garbage and dangling references
If a structure is destroyed before all access paths to the structure have been destroyed, any remaining paths become dangling references.
If the last access path to a structure is destroyed without the structure itself being destroyed and the storage recovered, then the structure becomes garbage

29. Garbage and Dangling References
If garbage accumulates, available storage is gradually reduced until the program may be unable to continue for lack of known free space
Dangling references create chaos.
If a program attempts to modify through a dangling reference a structure that has been already freed, the contents of an element on the free-space list my be modified inadvertently.
Modification overwrites the pointer linking the element to the next free-space-list element, making the entire list defective
this piece may now be used as a piece of the executable program, more trouble

30. Reference Counts
Reference counts - provides a way of checking the number of pointers to a given element so that no dangling references are created.
Within each element in the heap some extra space is provided for a reference counter

31. Reference Counter Algorithm
When an element is initially allocated from the free-space list, its reference count is set to one.
Each time a new pointer to the element is created, its reference count is incremented by 1.
Each time a pointer is destroyed, the reference count is decreased by 1.
When the reference count of an element reaches zero, the element is free and may be returned to the free-space list.

32. Garbage Problem
Looking at the basic problems of garbage and dangling reference, all of us would agree that dangling references are potentially far more damaging than garbage
The 2 problems are “related” - dangling references are freed too soon, garbage when freed too late.
When it is infeasible or too costly to avoid both problems, garbage generation is preferred
It is better not to recover storage at all than to recover it too soon.

33. Garbage Collection
Generally, allow garbage to accumulate to avoid dangling references
When free space is exhausted, computation is suspended temporarily and an extraordinary procedure is performed, garbage collection.
Garbage collection is done only rarely

34. Garbage Collection
Done in two stages:
Mark
and Sweep

35. Marking
Mark - first stage where each active element in the heap is marked. Each element must contain a garbage-collection bit set initially to “on”. The marking algorithm sets the garbage-collection bit of each active element “off”
The marking of garbage is the most difficult

36. Active Heap Element When is a heap element active?
Clearly, an element is active if there is a pointer to it from the outside the heap or from another active heap element
If it is possible to identify all such outside pointers and mark the appropriate, then iterate on these active active elements to other unmarked elements .. And so on, you could get the active elements

37. Underlying Assumptions
To use the before mentioned marking a fairly disciplined use of pointers is necessary:
Any active element must be reachable by a chain of pointers beginning outside the heap
It must be possible to identify every pointer outside the heap that points to an element inside the heap
It must be possible to identify within any active heap element the fields that contain pointers to other heap elements

38. Assumptions
LISP satisfies these assumptions, which permits garbage collection on LISP data
In C, assumptions 2 and 3 may not be true and if garbage collection were performed it would lead to dangling references

39. Sweep
Once the marking algorithm has marked active elements, all those remaining whose garbage-collection bit is “on” are garbage and may be returned to the free-space list

40. Heap Storage Management
Fixed or variable
If you have variable-size elements need variable
Problem is reuse of recovered space
If you recover 2 five-word blocks, it may be impossible to satisfy a request for a six word block
Reuse from free-space list - lots of algorithms (first-fit, best-fit, worst-fit)
fragmentation - no sufficiently large storage exist
full compaction (shifting of blocks to one end of the heap), partial compaction (only adjacent blocks combined)