0% found this document useful (0 votes)
48 views

Run Time Storage

The document discusses different methods for managing run-time storage including static allocation of memory at compile time, stack allocation using activation records, and dynamic memory allocation from the heap using techniques such as garbage collection; it also covers issues that can arise with different approaches and strategies for choosing memory chunks for allocation.

Uploaded by

Er Tanveer Kour
Copyright
© Attribution Non-Commercial (BY-NC)
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)
48 views

Run Time Storage

The document discusses different methods for managing run-time storage including static allocation of memory at compile time, stack allocation using activation records, and dynamic memory allocation from the heap using techniques such as garbage collection; it also covers issues that can arise with different approaches and strategies for choosing memory chunks for allocation.

Uploaded by

Er Tanveer Kour
Copyright
© Attribution Non-Commercial (BY-NC)
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/ 9

Run-Time Storage Data Area

Management • A data area is a block of storage for


variables and other objects known
to the compiler to have uniform stor-
age allocation requirements. Ex-
amples include global vars and structs.

Categories of Data To Be Considered Static Allocation

• constants - global and local • space requirements known at com-


pile (assembly) time
• global vars
– assembly languages
• static vars (inside functions)
– Fortran 77 and earlier
• recursive function calls
∗ fixed size arrays
• nested functions ∗ no dynamic mem alloc
• dynamic storage allocation ∗ no recursion
• space is allocated in a fixed location When and How?
for the lifetime of the program
• used for constants, global vars with • (data area, offset)
fixed size, vars local to a module – offset computed at compile time
(Modula-2), vars local to top-level
packages (Ada), static and extern – data area deferred to link or run
vars (C) time
– binding typically deferred in For-
tran until link time because of in-
dependently compiled modules

Address Binding • (register, offset)


• relate a variable or object to an ab- – load address of data area into reg-
solute address ister
– commonly available
– binding time deferred until just
before execution
– useful in a load and go environ-
ment, where no explicit link step
is performed
Stack Allocation Example(code supplied in class)
• began with Algol 60 • space is needed for variables - a,b,c
• required to support recursive proce- • space is needed for control info - say
dure calls 5 words
• each recursive call requires the allo- • literal 2.51 is stored in a static area
cation of a new copy of the proce- to avoid init with each call
dures local vars, so the number of • store addr of the data area in a reg
data objects needed cannot be de- • at compile time compute the offset
termined at compile time. of each variable from the beginning
of the AR.

Activation Records Extension – Dynamic Arrays


• All data space required for a pro- • Ada, Algol
cedure or function is treated as a
• size determined at runtime
data area called an activation record
(AR). • procedure allocates space for dynamic
arrays at runtime
• Activation records are the stack ob-
jects • uses a dope vector
– Push when a procedure or func-
tion is called
– Pop when it returns
Dope Vectors Problems
• placed in AR of procedure contain- • static or own variables
ing the array’s type declaration • Coroutines
• fixed size • Shared vars
• contains size and bounds of the ar-
ray, computed by evaluating the dec-
laration
• once initialized, space can be allo-
cated

• one pointer for each array (fixed num- • static or own variables
ber) points to the beginning of the – usually placed in static area (global)
array
– Algol 60 allows own vars for dy-
• now push variable-sized space onto namic arrays
AR local to procedure – severe difficulties with implemen-
• push and pop with the rest of the tation
AR
• Coroutines Displays
– Ada and Modula-2 • What if the number of ARs exceeds
– each process must have its own the number of available registers?
stack • each process has a static nesting level
– allocate entire stacks by heap al- determined by the structure of the
location program
• only one process at any nesting level
can have its vars accessed
• allocate one register for each nesting
level (may need a max nesting level)

• Shared vars • the set of these registers is a display


– Ada, Simula, some Lisp’s D
– two processes share non-local vars • D(i) points to the currently accessi-
– stacks are built in sharable seg- ble AR at level
ments • many ARs on stack, only a few are
– cactus stacks accessible
– a shared segment should not be • registers must be updated as a pro-
deallocated until all processes shar- cedure returns:
ing it are terminated – every call sets up the display for
the called process,
– a return restores the previous dis- Heap Allocation
play.
• A heap is a storage pool
– Rule: the value of the display
register at the level that is be- • most flexible and expensive storage
ing called is saved in the display scheme
area in the AR of the callee (one • objects can be allocated and freed in
word) any order

Block-level Nesting Allocation


• Algol 60, Ada, C • explicit
• deepens nesting levels – allocate in PL/1,
• can use a block-level AR – new in Pascal and Ada,
– malloc in C
• can use a procedure-level AR:
• implicit
– relative location of vars in blocks
can be determined at compile time – snobol str = str . ’xyz’
because blocks are entered and – lisp (cons a b)
exited in textual order • strategy: allocate until you run out
Deallocation Explicit
• problem because space can be allo- • programmer frees space by issuing
cated in any order deallocate commands
• stragegies: ignore, explicit, and im- • heap manager keeps track of free space-
plicit leaves hard decision on when to free
space to the program
• free in C, dispose in Pascal
• problem: dangling pointers

Ignore Implicit
• ok if most objects stay in use and • garbage collection
memory is large • many schemes
• program can maintain a free list of – single reference
disposed objects that can be reused
when a request for space is made – reference count
– mark and sweep
• well studied
Garbage Collection Strategies • mark and sweep
• single reference – follow all pointers and recursively
mark all accessible heap objects
– require no more than one refer-
ence (pointer) to any heap object – any object not marked can be freed
– if the reference is changed, free – sweep thru the heap, collect un-
the heap object marked objects, clear marks
– complex
– fairly easy to implement
– invoked only when needed
– ok for strings, but not links
– good for Lisp
– may have a compaction phase

• reference count Heap Management


– reference count is the number of How to choose a chunk of memory to
pointers to an object allocate?
– store a reference count with each
• best fit
object
– when reference count is zero, free – choose block that leaves the small-
the object est non-negative amount of waste
– must update when a pointer is – leads to many small and useless
created, copied, or destroyed pieces of memory
• first fit
– choose first chunk that is large
enough
– small pieces of memory tend to
cluster at front of a linked list
• circular first fit
– first fit, but continue from where
you were last time
– good choice

You might also like