storage management

Storage Management

• Different features in a language causes different storage

management techniques to be used.

– FORTRAN: no recursive calls, no dynamic storage

management.

– Pascal: stack-based storage management.

– LISP: garbage collection.

Language implementers decide about the details.

Programmers don’t know about it.

10/18/2012 Lovely Professional University,

Major Run-Time Elements Requiring

Storage

• Data

• Operations


Data and program Requiring Storage

• Code segments for translated user programs.

• System run-time programs.

– Supporting user programs.

– Like library routines, software interpreters or translator, storage

management routines.

• User-defined data structures and constants.

• Subprogram return points.


• Referencing environments.

– Identifier associations (LISP A-list)

• Temporaries in expression evaluation.

– Recursive function calls make it a lot.

• Temporaries in parameter transmission.

– Resulting values for evaluation of actual parameters are stored

in temporaries until the total evaluation is completed.



• Input-output buffers.

– Temporary storage areas used between the time of the actual

physical transfer of the data to or from external storage and

the program-initiated input / output operation.

• Miscellaneous system data.

– System data like tables, status information for input-output,

...



Storage organization

Subdivision of Runtime Memory

Typical subdivision of runtime memory into code and data

areas

code

Static data

stack

heap

The generated target code;

Data objects;

A counterpart of the control stack to

keep track of procedure activations


Storage allocation strategies

Storage allocation strategies are as follows:

– Static allocation

• Lays out storage for all data objects at compile time.

– Stack allocation

• Manages the run-time storage as a stack.

– Heap allocation

• Allocates and de-allocates storage as needed at run time from a heap.


Names are bound to storage as the program is compiled,

so there is no need for a run-time support package.

• Since the bindings do not change at run time,

• Every time a procedure is activated,

• Its names are bound to the same storage locations.

Static allocation


Some Limitations

– The size of a data object and constraints on its

position in memory must be known at compile

time.

– Recursive procedures are restricted, because all

activations of a procedure use the same

bindings for local name.

– Data structures cannot be created dynamically.


– A separate area of run-time memory, called

a heap.

– Heap allocation parcels out pieces of

contiguous storage, as needed for activation

records or other objects. Pieces may be de-

allocated in any order.

I -11 J -11 X 0 A -21

Heap allocation


Heap allocation is useful if either of the following is

possible.

1. The value of local names must be retained when

an activation ends.

2. A called activation outlives the caller.


Main idea

– Based on the idea of a control stack; storage is

organized as a stack, and activation records are pushed

and popped as activations begin and end, respectively.

– Storage for the locals in each call of a procedure is

contained in the activation record for that call.

– Locals are bound to fresh storage in each activation


“i “ is bounded to the most recently created i


Binding of names • Same name may denote different data objects

(i.e., locations) at runtime

• Two mapping are used

– Environment

• maps a name to a storage (or binding of a name to a storage)

– State

• maps storage to value

name locatio

n value

environment state


Procedure, Activation and Lifetime

• A procedure is activated when called

• The lifetime of an activation of a procedure is the sequence of steps between the first and last steps in the execution of the procedure body

• A procedure is recursive if a new activation can begin before an earlier activation of the same procedure has ended


Activation Records/Frames

A contiguous block of storage that stores information needed

by a single execution of a procedure

A general activation record

Returned value

Actual parameters

Optional control link

Optional access link

Saved machine status

Local data

temporaries

Such as those values in the evaluation of expressions

Data that is local to the execution of a procedure

Information about the state of the machine just before the procedure

is called

Refer to non-local data held in other activation records/fixed place

Point to the activation record of the caller

Used by the caller to supply parameters to the callee

The value that the callee return to caller


Activation Trees Activation trees

Represents the activations of procedures during program execution using a tree

Activation of procedure

› Execution of a procedure body

› Lifetime of activation Sequence of steps between first and last statements

Non-overlapping,

nested activation,

Recursive if a new activation can begin before an earlier activation of the same procedure

has ended.


Activation Trees

A tree to depict the control flow enters and leaves activation of a procedure

f(4)

f(3) f(2)

f(2) f(1) f(1) f(0)

f(1) f(0)

Enter f(4) Enter f(3) Enter f(2) Enter f(1) Leave f(1) Enter f(0) Leave f(0) Leave f(2) Enter f(1) Leave f(1) Leave f(3)

Enter f(2) Enter f(1) Leave f(1) Enter f(0) Leave f(0) Leave f(2) Leave f(4)


parent

Occurs

first


• Each node represents an activation of a procedure

• The root represents the activation of the main program

• The node for a is the parent of the node for b if and only if the control flows from activation of a to b, and

• The node for a is to the left of the node for b if and only if the lifetime of a occurs before the lifetime of b.


Control Flow • The control flow in a program P corresponds

to depth-first traversal of activation tree – Starts at the root

– Visits a node before its children

– Recursively visits children at each node from left-to-right

– The sequence of procedure calls corresponds to a preorder traversal of the activation tree

– The sequence of returns corresponds to postorder traversal of the activation tree


Sequences of Calls and Returns • Procedures calls implemented by calling Sequences

• Calling sequences consists of code that allocates an activation record on the stack by entering information into the fields

• Return sequences same as code to calling sequences – They restore the state of the machine in a way that the caller can

continue its execution

• Code in calling sequences divided between Caller and Callee

• In general, if procedure p calls Procedure q – The activation of q terminates normally

– The activation of q aborts and p ends at the same time

– The activation of q terminates due to some exception. The procedure p may or may not terminate


Activation Records: Control Stack (or run-time Stack)

• Control stack (run-time stack) – Keeps track of live procedure activation (or

FRAME)

• Where the root of the activation tree is at the bottom of the stack – Having node nj on the top of the stack means

• There exists a path in Activation tree from node nj to the root

• E.g,

– <root,…,ni, nj>


e.g., If control is currently in the activation write() of the tree, then activation

record for write() is at the top of the control stack.

Below it is the activation record for output(), and the bottom is the activation

record for main()


• In this example, as is true in general, procedure activations are nested in time. If an activation of procedure p calls procedure q, then that activation of q must end before the activation of p can end.

• There are three common cases:

1. The activation of q terminates normally. Then in essentially any language, control resumes just after the point of p at which the call to q was made.

2. The activation of q, or some procedure q called, either directly or indirectly, aborts; i.e., it becomes impossible for execution to continue. In that case, p ends simultaneously with q.

3. The activation of q terminates because of an exception that q cannot handle. Procedure p may handle the exception, in which case the activation of q has terminated while the activation of p continues, although not necessarily from the point at which the call to q was made. If p cannot handle the exception, then this activation of p terminates at the same time as the activation of q, and presumably the exception will be handled by some other open activation of a procedure


Designing Calling Sequences

• Values communicated between caller and callee are generally placed at the beginning of callee’s activation record

• Fixed-length items: are generally placed at the middle

• Items whose size may not be known early enough: are placed at the end of activation record

• We must locate the top-of-stack pointer judiciously: a common approach is to have it point to the end of fixed length fields.


Calling Sequence

• The caller evaluates the actual parameters

• The caller stores a return address and the old value of top-sp into the callee's activation record.

• The callee saves the register values and other status information.

• The callee initializes its local data and begins execution.


Implementing Variable Length Data layout on Stack: Another Example

• Procedure p calls procedure q

• P has three local arrays

• Sizes of arrays are not determined at compile time


Access to dynamically allocated arrays (NOTE: Here the top of the stack is downwards)

Ref. Text book 10/18/2012 Lovely Professional University,

Top and top-sp pointers

• Top - marks the actual top of the stack ( next activation record will begin at this location)

• Top-sp - locates the fixed length fields of the top activation record

• These are restored from the saved control link in the activation record of the called function


Reposition of top and top-sp

• Positions of these pointers is computed in terms of sizes that will be known at run time

• Code to reposition these is generated at compile time


Better Alternative

• Allocate dynamic data on heap

• Maintain only the address of the allocated memory (fixed )

[heap memory management will be discussed later while discussion on garbage collection]


Static versus dynamic memory allocation

Static – Storage allocation decision is static if it can be made by the compiler only by looking at the source code text

example: all variables of fixed size

struct sample { int x, y; float u,v,w;}

Dynamic –

Storage allocation decision is dynamic if it is based on execution of the program e.g.

(1) allocation of memory (heap) through malloc() etc

(2) allocation of memory (stack) during function calls


Access Links: Nested procedure definitions

(Example language-only looks like C) fun1()

{

integer a,b,c;

a=2;b=3;c=4;

integer fun2()

{

integer c,d,e;

c=5;d=7;

e=a+b+c+d;

return e;

}

}

fun1:

Locals : a,b,c

fun2:

Locals : c,d,e

fun2 needs to access values of a

and b

c is redefined in fun 2

Access link is required

C does not require this feature as the

scope of variables is within the function

definition


d=7

Access link-none

Returned values-none

Control link – to self/driver

Actual parameter - none xFFF

C

xFFF

8

xFFF

4

xFFF

0

xFFE

C

xFFE

8

xFFE

4

xFFE

0

Control links-to fun1

Returned value ‘e’

Actual parameter -none

a=2

Link(=xFFFC for example) to access values a,b

c=5

xFFD

C

xFFD

8

xFFD

4

xFFD

0

b=3

c=4 Activation

record of fun1()

Fixed variables

Activation

record of fun2()

NOTE:

1. Sizes of the activation records for different functions are different

2. Some fields are common in all activation records

The nesting

depth of 1 is

handled here


An example : Let the nesting depth of p be np

q()

{ int b

…

w(){ int d;

…………….f(){ int e;

………….. s(){

p(){

int a;

a=b+d+e;

}

}

}

}

Assuming b,c,d

are not redefined 10/18/2012 Lovely Professional University,

Whose activation record is at the top?

Activation Record of q()

Activation Record of w()

……

……

Activation Record of s()

Activation Record of f()

……

Activation Record of p() p() (at nesting depth np)

needs to access different

activation records

np >=nq


storage management

Documents

lovely professional

fixed length

control flow

nesting depth

heap allocation

status information

actual parameter

actual parameters