0% found this document useful (0 votes)
44 views7 pages

Memory Management: Runtime

Dynamic memory allocation is required at runtime for activation records, objects, and other implicit and explicit allocations. Programming languages provide memory management through runtime systems that allocate and deallocate memory dynamically. Memory can be modeled as arrays or regions granted to each program by the operating system. Memory is typically allocated on a stack for activation records using a push on call and pop on return model, or from a heap which is a pool of variable-sized memory blocks.

Uploaded by

medany2000
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)
44 views7 pages

Memory Management: Runtime

Dynamic memory allocation is required at runtime for activation records, objects, and other implicit and explicit allocations. Programming languages provide memory management through runtime systems that allocate and deallocate memory dynamically. Memory can be modeled as arrays or regions granted to each program by the operating system. Memory is typically allocated on a stack for activation records using a push on call and pop on return model, or from a heap which is a pool of variable-sized memory blocks.

Uploaded by

medany2000
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/ 7

Dynamic Memory Allocation

 We need memory at runtime:


– Activation records
– Objects
Memory Management – Explicit allocations: new, malloc, etc.
– Implicit allocations: strings, file buffers, arrays with
dynamically varying size, etc.
 Language systems provide an important hidden
player: runtime memory management
It is a 800-pages topic, but here
we want to do it in one classe!
11/13/2007 ITK 327 1 11/13/2007 ITK 327 2

Memory Model Yes! Its OS’s job!! Memory Managers In Java


public class MemoryManager {
 For now, assume that the OS grants each private int[] memory;

running program one or more fixed-size /* MemoryManager constructor. */


regions of memory for dynamic allocation
public MemoryManager(int[] initialMemory) {
 We will model these regions as an arrays memory = initialMemory;
}
– To see examples of memory management code …

(Our textbook is in the Java area)

11/13/2007 ITK 327 3 11/13/2007 ITK 327 4

Stacks Of Activation Records A Stack Illustration


A simple memory management problem
top: 8
An empty stack of 8
 Activation records must be allocated 7:
words.
reg.
dynamically 6:

 For many PL, it suffices to allocate on call 5:

and deallocate on return 4:

3:
 This produces a stack of activation records:
grow 2:
Why not link list?
push on call, pop on return
1:

0:

11/13/2007 ITK 327 5 11/13/2007 ITK 327 6

1
Some program P needs 3 words Some program Q needs 2 words

top: 4 The manager program calls top: 1 The manager program calls
7:
m.push(3). 7:
m.push(2).

6: first activation 6: first activation


record record
P gets this 5: P gets this 5:
pointer pointer
4: 8 4: 8

3: 3:
second
2: Q gets this 2: activation record
pointer
1: 1: 4

0: 0:
wasted

11/13/2007 ITK 327 7 11/13/2007 ITK 327 8

How to deal blocks to the requests?


Heap
 A linked list of free blocks, initially containing one
 Stack is easy to do, but big free block, then fragmented into small blocks

Allocations and deallocations may come in any order?


The easiest approach: First Fit for request
 A heap is a pool of blocks of memory – Search free list for first adequate block
– If there is extra space in the block, return the unused
(At the beginning there is (may be) only one block) portion at the upper end to the free list
– Allocate requested portion (at the lower end)
 There are many mechanisms for this…
 To free, just add to the front of the free list

11/13/2007 ITK 327 9 11/13/2007 ITK 327 10

Heap implementation
9:
in an array 9:
8:
8:
7:
7:
6:
6: -1
5:
Some program P Size of this block
5: 5
4: requests 4 words
4:
3:

2:
Pointer to next P gets this 3:
first allocated
block pointer 2:
block
1: -1
1:
freeStart: 0 0: 10

Size of this block freeStart: 5 0: 5 Size of this block

11/13/2007 ITK 327 11 11/13/2007 ITK 327 12

2
Some program Q 9:
9: -1 -1
requests 2 words 9: -1
8: 2 8: 2
8: 2 7:
second allocated
Q gets this block
7:
second allocated
7: 6:
pointer second allocated
6: block
6: block 5: 3

4: 5: 3
Size of this block 5: 3
3: 4:
first allocated
4: block
2:
3:
3: 1:
P is done
first allocated
2:
block freeStart: 8 0: 5
2:
1: 8
1:
freeStart: 0 0: 5
freeStart: 8 0: 5

11/13/2007 ITK 327 13 11/13/2007 ITK 327 14

9:

8:
-1
A Problem
2

7:
second allocated
 Consider this sequence:
Some program R block
6:
p1=m.allocate(4); -1
requests 1 word p2=m.allocate(4);
5: 3
m.deallocate(p1);
5
4: m.deallocate(p2);
p3=m.allocate(7);
3: 8
R gets this
2: 3
pointer
1:
third allocated  The manager needs to coalesce
block 5
freeStart: 2 0: 2 adjacent free blocks 5

11/13/2007 ITK 327 15 11/13/2007 ITK 327 16

Improvement strategy Fragmentation


9:

8: -1
p1=m.allocate(4);
 Keep separate free lists for popular (small) p2=m.allocate(1); 7: 3
block sizes m.deallocate(p1); 6:
second allocated
block
p3=m.allocate(5);
 Quick lists, a separate list, blocks are one 5: 2
The final allocation will fail because
size of fragmentation. 4:

 Delayed coalescing: not coalesced right 3:

away (but may have to be coalesced DeFragmentation 2:

eventually) 1: 7

freeStart: 0 0: 5

11/13/2007 ITK 327 17 11/13/2007 ITK 327 18

3
Heap Mechanisms Placement
 Many variety  Where to allocate a block
 Three major issues:  Our mechanism: first fit from FIFO free list
– Placement—where to allocate a block  Some mechanisms use a similar linked list
– Splitting—when and how to split large blocks of free blocks: first fit, best fit, next fit, etc.
– Coalescing—when and how to recombine  Some mechanisms use a more scalable data
 Many refinements structure like a balanced binary tree

11/13/2007 ITK 327 19 11/13/2007 ITK 327 20

Splitting Coalescing
 When and how to split large blocks  When and how to recombine adjacent free
 Our mechanism: split to requested size blocks
 Sometimes you get better results with less  Several varieties:
splitting—just allocate more than requested – No coalescing
or rounding up allocation size to some – Eager coalescing
multiple – Delayed coalescing (as with quick lists)

11/13/2007 ITK 327 21 11/13/2007 ITK 327 22

Current Heap Links Tracing Current Heap Links

What if the running program can operate the start:


a: 2
addresses allocated to it? b: 2 1
IntList a =
c: 1 (an IntList) new IntList(null);
a free int b = 2;
a = new X(i); (activation record
for main) head: 2
int c = 1;
b = new X(j); b tail: null a = a.cons(b);
a = a.cons(c);
a = b; (a ConsCell)
3
free
head: 1 Where are the current
free tail:
heap links in this
 Some systems track current heap links (a ConsCell) picture?
 A current heap link is a memory location where free
the running program will use as a heap address
the stack the heap

11/13/2007 ITK 327 23 11/13/2007 ITK 327 24

4
Discarding Impossible Links
To Find Current Heap Links
 Depending on the language and
 Start with the root set: memory locations outside implementation, we may be able to discard
of the heap with links into the heap {a b c }
– Active activation records (if on the stack)
some locations from the set:
– Static variables, etc. They are not in the active – If they do not point to/into allocated heap blocks (Java,
activation record. but not C)
– If their dynamic type rules out use as heap links
 For each memory location in the set, look at the
allocated block it points to, and add all the – If their static type rules out use as heap links (Java, but
not C)
memory locations in that block
 Repeat until no new locations are found

11/13/2007 ITK 327 25 11/13/2007 ITK 327 26

Errors In Current Heap Links


Errors Are Unavoidable
 Exclusion errors: a memory location that actually
is a current heap link is left out. (This type of
 For heap manager purposes, exclusion errors are
error is not allowed)
unacceptable
 Unused inclusion errors: a memory location is
included, but the program never actually uses the
value stored there Therefore, we must include a location if it might be
used as a heap link, and
 Used inclusion errors: a memory location is
 This makes unused inclusion errors unavoidable
included, but the program uses the value stored
there as something other than a heap address—as  Depending on the language, used inclusions may
an integer, for example also be unavoidable

11/13/2007 ITK 327 27 11/13/2007 ITK 327 28

Heap Compaction  There are so many errors caused by improper


Defragmentation deallocation (C, C++, Bad or without class
destructors..)
 One application for current heap links
 It is a burden on the programmer to have to worry
 Manager can move allocated blocks: about it…
– Copy the block to a new location
– Update all links to (or into) that block
Therefore, let the language system do the job
 So it can compact the heap, moving all
automatically --- Garbage Collection
allocated blocks to one end, leaving one big
free block and no fragmentation

11/13/2007 ITK 327 29 11/13/2007 ITK 327 30

5
Three Major Approaches Mark And Sweep
 Mark and sweep  A mark-and-sweep collector uses current heap
links in a two-stage process:
 Copying – Mark: find the live heap links and mark all the heap
blocks linked to by them
 Reference counting – Sweep: make a pass over the heap and return unmarked
blocks to the free pool

- both kinds of inclusion errors are


tolerated,
- blocks are not moved, fragmentation
may remain

11/13/2007 ITK 327 31 11/13/2007 ITK 327 32

Copying Collection Reference Counting


 A copying collector divides memory in half, and  Each block has a counter of heap links to it
uses only one half at a time
 Incremented when a heap link is copied,
 When one half becomes full, find live heap links,
and copy live blocks to the other half decremented when a heap link is discarded
 Compacts as it goes, so fragmentation is  When counter goes to zero, block is garbage
eliminated and can be freed
 Moves blocks: cannot tolerate used inclusion
errors, because that used variable will be mistaken  Does not use current heap links
as a link and hence modified

11/13/2007 ITK 327 33 11/13/2007 ITK 327 34

Reference Counting Problem Reference Counting Problem


circle: 2 1
link: circle: null
link:

(activation record) One problem with (activation record) When circle is set
free reference counting: it free to null, the reference
1 misses cycles of 1 counter is
link: link:
garbage. decremented.
free free
Here, a circularly free No reference counter
free
link:
1 linked list is pointed link:
1 is zero, though all
to by circle. blocks are garbage.

free free
the stack the stack
the heap the heap

11/13/2007 ITK 327 35 11/13/2007 ITK 327 36

6
Reference Counting Garbage Collecting Refinements
 Problem with cycles of garbage  Generational collectors
 Problem with performance generally, since – Divide block into generations according to age
the overhead of updating reference counters – Garbage collect in younger generations more
is high often (using previous methods)
 One advantage: naturally incremental, with  Incremental collectors
no big pause while collecting – Collect garbage a little at a time
– Avoid the uneven performance of ordinary
mark-and-sweep and copying collectors

11/13/2007 ITK 327 37 11/13/2007 ITK 327 38

Garbage Collecting Languages


Conclusion
Some P.L.’s are
 required: Java, ML  Memory management is an important
 encouraged: Ada
hidden player in language systems
 Performance and reliability are critical
 difficult to have: C, C++
 Different techniques are difficult to
– Even for C and C++ it is possible
compare, since every run of every program
– There are libraries that replace the usual makes different memory demands
malloc/free with a garbage-collecting
 Still an active area of language systems
manager
research and experimentation

11/13/2007 ITK 327 39 11/13/2007 ITK 327 40

You might also like