0% found this document useful (0 votes)
237 views16 pages

Object Lifetime and Storage Management

The document discusses object lifetime and storage management. It describes the lifetime of objects and bindings. It also explains the three main storage allocation mechanisms: static allocation for objects that don't change, stack allocation for function arguments and local variables, and heap allocation for dynamically allocated objects.

Uploaded by

lija
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
237 views16 pages

Object Lifetime and Storage Management

The document discusses object lifetime and storage management. It describes the lifetime of objects and bindings. It also explains the three main storage allocation mechanisms: static allocation for objects that don't change, stack allocation for function arguments and local variables, and heap allocation for dynamically allocated objects.

Uploaded by

lija
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

CHAPTER – 2

OBJECT LIFETIME AND STORAGE MANAGEMENT

Object Lifetime
 Period of time between the creation and destruction of the object.
 Example: time between creation and destruction of a dynamically allocated
variable in C++ using new and delete

 Key events in object lifetime


 Object creation
 Creation of bindings
 References to variables, subroutines, types are made using bindings
 Deactivation and reactivation of temporarily unusable bindings
 Destruction of bindings
 Destruction of objects

Binding lifetime
 Period of time between the creation and destruction of a name to object binding
is called the binding’s lifetime. (Name-to-object association)
 E.g. a Java reference variable is assigned the address of an object
 E.g. a function's formal argument is bound to an actual argument (object)

Two common mistakes

 Dangling reference: no object for a binding (e.g., a pointer refers to an


object that has already been deleted). INT A=5; IF 5 IS DESTROYED.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


 Memory leak: no binding for an object (preventing the object from being
deallocated) IF A IS DESTROYED

Object Lifetime Example


Example C++ fragment:

{ SomeClass& myobject = *new SomeClass;


...
{ OtherClass& myobject = *new OtherClass;
... myobject // is bound to other object
...
}
... myobject // is visible again
...
delete myobject;
}

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


Object Storage Management / (Storage Allocation Mechanism)
 An object has to be stored somewhere in memory during its lifetime
 An object’s lifetime corresponds to one of the three principal storage allocation
mechanism used to manage the space where the object resides.

1. Static objects
 Objects have an absolute storage address that is retained throughout the
execution of the program.
 Static values are assigned with absolute address.
 Static values will not change during the execution. Eg., Global variables
 Object’s lifetime spans the whole execution of the program.
 Subroutine code
 Class method code

2. Stack objects
 Objects are allocated in last-in first-out (LIFO) order, usually in
conjunction with subroutine calls and returns.
 Stackframe is allocated based on subroutine/ function call.
 Stack deallocates on function return.
 Object’s lifetime spans period between invocation of the subroutine and
return from the subroutine.
 Actual arguments of a subroutine
 Local variables of a subroutine

3. Heap objects
Dr Sruthy S, PP, S7CSE-B, SJCET Palai
 Object stored on heap.
 Run Time Objects may be allocated and deallocated (created/destroyed)
at arbitrary times
 Explicitly by programmer or
 Implicitly by garbage collector
 Heap objects require an expensive/ (COSTLIER mechanism) storage
management algorithm.
 E.g. Java class instances are always stored on the heap.

Typical Program and Data Layout in Memory

 Program code is at the bottom of the memory region (code section)


 Static data objects are stored in static region (data section)
 Stack grows downward (data section)
 Heap grows upward (data section)
 The code section is protected from run-time modification

1. Static Allocation- value stored should not change during the execution.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


Typical static subroutine data
memory layout:

 Program code is statically allocated in most implementations of imperative


languages.
 Statically allocated variables are history sensitive.
 Global variables.
 And a few Static local variables in C function retain value even after
function returns.
 Advantage of statically allocated object is the fast access due to absolute
addressing of the object.
 Static allocation does not work for local variables in potentially recursive
subroutines.
 Every (recursive) subroutine call must have separate instantiations of
local variables.
 Fortran 77 has no recursion
 Both global and local variables can be statically allocated as decided by
compiler.
 Avoids overhead of creation and destruction of local objects for every
subroutine call.
Eg1) Numeric Constants:
A=B/14.5
Dr Sruthy S, PP, S7CSE-B, SJCET Palai
Eg2) String Constant:
Printf(“hello”);
Eg3) Debugger, type checking, garbage collection, exception handling etc.
creates tables, these tables are examples of statically allocated objects.

2. Stack-Based Allocation

 The stack is used to allocate space for subroutines in languages that permit
recursion.
 During function call a stack frame is allocated and is deallocated on function
return.

Why we are not using static???


When we call the function invokes multiple times, we need to allocate
the memory for objects separately for each call/ invocation of function.
It results in memory overhead. That’s y we use stack.

Currently active subroutine is called Activation Record.


 Each instance of a subroutine at run time has a frame on the run-time stack (also
called activation record)
 Compiler generates subroutine calling sequence to setup frame, call the
routine, and to destroy the frame afterwards
 Subroutine prologue and epilogue code operate and maintain the frame.
 Frame layouts vary between languages and implementations

Book keeping= Miscellaneous Infrmn


Typical frame layout
Dr Sruthy S, PP, S7CSE-B, SJCET Palai
 A frame pointer (fp) points to the frame of the currently active subroutine at
run time (always topmost frame on stack)
 Subroutine arguments, local variables, and return values are accessed by
constant address offsets from frame pointer (fp).
 The stack pointer (sp) points to free space on the stack

Stack-Based Allocation Example

Step1: The Subroutine A is called first. Thus the corresponding stack frame is
created for Subroutine A.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


STEP2: From the subroutine A we calls the subroutine B. So the stack frame is
allocated for B.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


Step3: Then from subroutine B, we call subroutine A, hence stackframe is
created for A.

Currently if A is active, then the stackframe of A is called Activation Record.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


Example Frame

 The word sizes of the types of local variables and arguments determines the fp
offset in a frame.

Fp + displacement address can locate and access all the local variables
and its values.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


 The compiler determines the slots for the local variables and arguments in a
frame
 The fp of the previous active frame is saved in the current frame and restored
after the call

Stack Frame Before, During and After Subroutine Call

 The stack frame (activation record) stores


 Arguments and local variables of the subroutine,
 The return value(s) of the subroutine,
 The return address
 …..

 The subroutine calling sequence maintains the stack:


 Call executed by the caller immediately before and after call.
 Before call, the caller pushes arguments and return address onto the
stack.
 After being called 1. (prologue), the subroutine (“callee”)
initializes local variables, etc.
Call executed at beginning,
All local variables are initialized.
Dr Sruthy S, PP, S7CSE-B, SJCET Palai
 Before returning 2. (epilogue), the subroutine cleans up local data.
Code executed at the end.
 After the call returns, the caller retrieves return value(s) and restores
the stack to its state before the call.

 Compiler determines
 Frame pointer: a register pointing to a known location within the
current stack frame
 Offsets from the frame pointer specifying the location of objects in the
stack frame.
 The absolute size of the stack frame may not be known at compile time (e.g.,
variable-size arrays allocated on the stack).

 Stack pointer
• Register pointing to the first unused location on the stack (used as the
starting position for the next stack frame).

 Specified at runtime
Dr Sruthy S, PP, S7CSE-B, SJCET Palai
• The absolute location of the stack frame in memory (on the stack)
• The size of the stack frame

3. Heap-Based Allocation
 The heap is a region of memory where blocks can be allocated and deallocated
dynamically at arbitrary times and in arbitrary order.
 More unstructured
 Memory may become fragmented
 Need for garbage collection
 Implicit heap allocation:
 Java class instances are always placed on the heap
 Scripting languages and functional languages make extensive use of the
heap for storing objects
 Some procedural languages allow array declarations with run-time
dependent array size
 Resizable character strings.
 Explicit heap allocation:
 Statements and/or functions for allocation and deallocation
 Heap allocation is performed by searching heap for available free space.
 Deletion of objects leaves free blocks in the heap that can be reused.
 Disadvantage of heap based memory allocation are of 2 types. They are:
 Internal heap fragmentation: If allocated object is smaller than the free block
the extra space is wasted.
 External heap fragmentation: Smaller free blocks are scattered. And hence we
cannot place the objects.

Heap Allocation Algorithms (Storage Management algorithm)


 Storage management algorithms maintain a single linked list – the free list – of
blocks not in use.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai


Pool division

Strategies to manage space in a heap:

 First-fit: select the first large block and place the data.
 Best-fit: search entire list for the smallest free block that is large enough to hold
the object. If extra space is there, it’s added to free list.
 If an object is smaller than the block, the extra space can be added to the list of
free blocks
 When a block is freed, adjacent free blocks are coalesced
 Heap allocates memory in 2 ways:
 1) static allocation 2) Dynamic allocation
i. Buddy System ii.
Fibonacci Heap

 Buddy system: maintain heap pools of standard sized blocks of size 2k.
 If no free block is available for object of size between 2k-
1
+1 and 2kthen find block of size 2k+1and split it in half, adding the
halves to the pool of free 2k blocks, etc.
 Fibonacci heap: maintain heap pools of standard size blocks according to
Fibonacci numbers
 More complex but leads to slower internal fragmentation.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai



Storage Allocation Mechanisms Compared

Static Stack Heap


local variables of implicit: local variables of variable
fixed size and size; explicit: new (destruction with
Ada N/A
subroutine garbage collection or explicit with
arguments unchecked deallocation)
global variables; static local
variables, e.g. local variables and
explicit
C f() subroutines
with malloc and free functions
{ static int n; arguments
...
local variables and
global
C++ subroutine explicit: new and delete
variables; static members
arguments
local variables with implicit: all class instances
Java N/A primitive types (destruction with garbage
(e.g. intand char) collection)
global variables (in common
local variables and
blocks), local variables, and
subroutine
subroutine arguments
Fortran77 arguments N/A
(implementation
(implementation
dependent); SAVE forces
dependent)
static allocation
global variables
(dependent on
global variables (dependent compiler), local
Pascal explicit: new and dispose
on compiler) variables, and
subroutine
arguments

Garbage Collection (2 types):


Dr Sruthy S, PP, S7CSE-B, SJCET Palai
 Explicit manual deallocation errors are among the most expensive and hard
to detect problems in real-world applications
 If an object is deallocated too soon, a reference to the object becomes
a dangling reference, accessing memory now used by another object.
 If an object is not deallocated at the end of its life time, then the
program may leaks memory eventually running out of the heap space.

 Automatic garbage collection removes all objects from the heap that are not
accessible, i.e. are not referenced
 Used in Lisp, Scheme, Prolog, Ada, Java, Haskell
 Disadvantage is GC overhead, but GC algorithm efficiency has been
improved
 Not always suitable for real-time programming.

Dr Sruthy S, PP, S7CSE-B, SJCET Palai

You might also like