Garbage collection doesn't solve every memory deallocation problem. For example, if a root to a large data structure is kept, the garbage collector cannot reclaim it, even if it is never referred to again. To eliminate this problem, it is good practice to set a reference or pointer to an object to null when no longer needed.
This advice applies only to static references or references embedded inside other objects. There is not much point for such stored on the stack to be nulled, since the collector doesn't scan for roots past the top of the stack, and because new stack frames are initialized anyway.
Memory Management
Any non-trivial program needs to allocate and free memory. Memory management techniques become more and more important as programs increase in complexity, size, and performance. D offers many options for managing memory.
The three primary methods for allocating memory in D are:
-
Static data, allocated in the default data segment.
-
Stack data, allocated on the CPU program stack.
-
Garbage collected data, allocated dynamically on the garbage collection heap.
This chapter describes techniques for using them, as well as some advanced alternatives:
-
Strings (and Array) Copy-on-Write
-
Real Time
-
Smooth Operation
-
Free Lists
-
Reference Counting
-
Explicit Class Instance Allocation
-
Mark/Release
-
RAII (Resource Acquisition Is Initialization)
-
Allocating Class Instances On The Stack
Strings (and Array) Copy-on-Write
Consider the case of passing an array to a function, possibly modifying the contents of the array, and returning the modified array. Since arrays are passed by reference, not by value, a crucial issue is who owns the contents of the array? For example, a function to convert an array of characters to upper case:
char[] toupper(char[] s)
{
int i;
for (i = 0; i < s.length; i++)
{
char c = s[i];
if ('a' <= c && c <= 'z')
s[i] = c - (cast(char)'a' - 'A');
}
return s;
}
Note that the caller's version of s[] is also modified. This may be not at all what was intended, or worse, s[] may be a slice into a read-only section of memory.
If a copy of s[] was always made by toupper(), then that will unnecessarilly consume time and memory for strings that are already all upper case.
The solution is to implement copy-on-write, which means that a copy is made only if the string needs to be modified. Some string processing languages do do this as the default behavior, but there is a huge cost to it. The string "abcdeF" will wind up being copied 5 times by the function. To get the maximum efficiency using the protocol, it'll have to be done explicitly in the code. Here's toupper() rewritten to implement copy-on-write in an efficient manner:
char[] toupper(char[] s)
{
int changed;
int i;
changed = 0;
for (i = 0; i < s.length; i++)
{
char c = s[i];
if ('a' <= c && c <= 'z')
{
if (!changed)
{ char[] r = new char[s.length];
r[] = s;
s = r;
changed = 1;
}
s[i] = c - (cast(char)'a' - 'A');
}
}
return s;
}
Copy-on-write is the protocol implemented by array processing functions in the D Phobos runtime library.
Real Time
Real time programming means that a program must be able to guarantee a maximum latency, or time to complete an operation. With most memory allocation schemes, including malloc/free and garbage collection, the latency is theoretically not bound. The most reliable way to guarantee latency is to preallocate all data that will be needed by the time critical portion. If no calls to allocate memory are done, the gc will not run and so will not cause the maximum latency to be exceeded.
Smooth Operation
Related to real time programming is the need for a program to operate smoothly, without arbitrary pauses while the garbage collector stops everything to run a collection. An example of such a program would be an interactive shooter type game. Having the game play pause erratically, while not fatal to the program, can be annoying to the user. There are several techniques to eliminate or mitigate the effect:
Preallocate all data needed before the part of the code that needs to be smooth is run.
Manually run a gc collection cycle at points in program execution where it is already paused. An example of such a place would be where the program has just displayed a prompt for user input and the user has not responded yet. This reduces the odds that a collection cycle will be needed during the smooth code.
Call gc.disable() before the smooth code is run, and gc.enable() afterwards. This will cause the gc to favor allocating more memory instead of running a collection pass.
Free Lists
Free lists are a great way to accelerate access to a frequently allocated and discarded type. The idea is simple - instead of deallocating an object when done with it, put it on a free list. When allocating, pull one off the free list first.
class Foo
{
static Foo freelist; // start of free list
static Foo allocate()
{ Foo f;
if (freelist)
{ f = freelist;
freelist = f.next;
}
else
f = new Foo();
return f;
}
static void deallocate(Foo f)
{
f.next = freelist;
freelist = f;
}
Foo next; // for use by FooFreeList
...
}
void test()
{
Foo f = Foo.allocate();
...
Foo.deallocate(f);
}
Such free list approaches can be very high performance.
-
If used by multiple threads, the allocate() and deallocate() functions need to be synchronized.
-
The Foo constructor is not re-run by allocate() when allocating from the free list, so the allocator may need to reinitialize some of the members.
-
It is not necessary to practice RIAA with this, since if any objects are not passed to deallocate() when done, because of a thrown exception, they'll eventually get picked up by the gc anyway.
Share with your friends: |