[go: up one dir, main page]
Scribd
Upload
428 views19 pages

Storage Management

This document discusses memory management techniques. It explains that programs use stacks to allocate memory for local variables and parameters which is automatically freed when functions return. Heap memory can be dynamically allocated and freed by the programmer, requiring careful management of pointers and references to avoid bugs. While C/C++ require manual memory management, modern languages like Java use garbage collection to automatically free unused memory, though it can cause occasional performance issues.

Uploaded by

Aneeb Arayilakath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
428 views19 pages

Storage Management

This document discusses memory management techniques. It explains that programs use stacks to allocate memory for local variables and parameters which is automatically freed when functions return. Heap memory can be dynamically allocated and freed by the programmer, requiring careful management of pointers and references to avoid bugs. While C/C++ require manual memory management, modern languages like Java use garbage collection to automatically free unused memory, though it can cause occasional performance issues.

Uploaded by

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

Storage Management

The stack and the heap


Dynamic storage allocation refers to
allocating space for variables at run time
Most modern languages support dynamic
storage allocation on both a stack and a heap
It is possible to have many stacks and heaps
Allocated storage must eventually be
deallocated (freed)

The stack
When you enter a subprogram (function,
procedure, method), space is allocated on the
stack for
local variables
formal parameters

This space persists until the subprogram


returns
Storage allocation/deallocation is simple

Using the stack


Stack allocation/deallocation is automatic
You have names for variables on the stack
because they're local variables or parameters

Stack allocation is perfect for recursion


Recursive calls use the same names but different
storage

The storage is released when function exits


This is not always what you want

Purpose of the heap


Suppose you write a function whose job is to
create a data structure, and suppose that data
structure is placed on the stack
The data structure disappears when you exit
the function
You need dynamic storage that you, the
programmer, can control
The heap provides that dynamic storage

Pointers
Allocating storage from the heap is easy
Person p = new Person ( );

You get a pointer to the new storage


C and C++ provide operations on pointers
For example, p++;
You can have many pointers to the same storage

Pointers are pervasive in C and C++; you can't


avoid them

References
The Java name for pointers is references
The only real difference is that Java does not
provide (many) operations on pointers

Pointer arithmetic is inherently unsafe


You can accidentally point to the wrong thing
You cannot in general be sure of the type of the
thing you are pointing to
Java avoids these problems

Advantages/disadvantages
Pointers give you:
Greater flexibility and (maybe) convenience
A much more complicated syntax
More ways to create hard-to-find errors

References give you:


Less flexibility (no pointer arithmetic)
Simpler syntax, like that of any other variable
Much safer programs with fewer mysterious bugs

Deallocation
There are two potential errors when
deallocating (freeing) storage yourself:
Deallocating too soon, so that you have
dangling references (pointers to storage that has
been freed and possibly reused for something
else)
Forgetting to deallocate, so that unused storage
accumulates and you have a memory leak

Ownership
If you have to deallocate storage yourself, a
good strategy is that of ownership
The function that owns the storage is
responsible for deallocating it
Ownership can be transferred
You just need a clearly defined policy for
determining ownership
In practice, this is easier said than done

Discipline
Most C/C++ advocates say:
It's just a matter of being disciplined
I'm disciplined, even if other people aren't
Besides, there are good tools for finding
memory problems

However:
Virtually all large C/C++ programs have
memory problems

Garbage collection
Garbage is storage that has been allocated but
is not longer available to the program
It's easy to create garbage; just assign a new
value to the pointer to that storage
A garbage collector automatically searches
out garbage and deallocates it
Practically every modern language, except C+
+, uses a garbage collector

Garbage collection algorithms


There are two well-known algorithms (and
several not so well known ones) for doing
garbage collection:
Reference counting
Mark and sweep

Reference counting
When storage is allocated, make it a bit larger
so it can hold an integer reference count
The reference count keeps track of how many
pointers the program has to the storage
Any assignment to a pointer variable modifies
reference counts
When a reference count reaches zero, the
storage can be garbage collected

Problems with reference counting


If A points to B, and B points to A, then
each is referenced, even if nothing else in
the program points to either one
This fools the garbage collector, which
doesn't collect either A or B
Thus, reference counting is imperfect and
unreliable; memory leaks still happen

Mark and sweep


When memory runs low, stop processing and
run the garbage collector
The collector marks every bit of heap storage
It then looks at every program variable,
follows every pointer, and unmarks all the
storage it can reach
When done, the marked storage must not be
accessible; it is garbage that can be freed

Problems with mark and sweep


Mark-and-sweep is a complex algorithm
that takes substantial time
Unlike reference counting, it must be done
all at once--nothing else can be going on
The program stops responding during
garbage collection
This is unsuitable for real-time applications

Garbage collection in Java


Java uses mark-and-sweep
Highly reliable, but may cause unexpected
slowdowns
You can ask Java to do garbage collection
when the program has some time to spare
But not all implementations respect your request

This problem is known and being worked on

The End

You might also like