Storage Management

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
  -gt 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 evaluationTemporaries
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 buffersMiscellaneous 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
operationsComponent 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)