Garbage Collection

D is a fully garbage collected language. That means that it is never necessary to free memory. Just allocate as needed, and the garbage collector will periodically return all unused memory to the pool of available memory.

C and C++ programmers accustomed to explicitly managing memory allocation and deallocation will likely be skeptical of the benefits and efficacy of garbage collection. Experience both with new projects written with garbage collection in mind, and converting existing projects to garbage collection shows that:

• Garbage collected programs are often faster. This is counterintuitive, but the reasons are:
  • Reference counting is a common solution to solve explicit memory allocation problems. The code to implement the increment and decrement operations whenever assignments are made is one source of slowdown. Hiding it behind smart pointer classes doesn't help the speed. (Reference counting methods are not a general solution anyway, as circular references never get deleted.)
  • Destructors are used to deallocate resources acquired by an object. For most classes, this resource is allocated memory. With garbage collection, most destructors then become empty and can be discarded entirely.
  • All those destructors freeing memory can become significant when objects are allocated on the stack. For each one, some mechanism must be established so that if an exception happens, the destructors all get called in each frame to release any memory they hold. If the destructors become irrelevant, then there's no need to set up special stack frames to handle exceptions, and the code runs faster.
  • Garbage collection kicks in only when memory gets tight. When memory is not tight, the program runs at full speed and does not spend any time tracing and freeing memory.
  • Garbage collected programs do not suffer from gradual deterioration due to an accumulation of memory leaks.
• Garbage collectors reclaim unused memory, therefore they do not suffer from "memory leaks" which can cause long running applications to gradually consume more and more memory until they bring down the system. GC programs have longer term stability.
• Garbage collected programs have fewer hard-to-find pointer bugs. This is because there are no dangling references to freed memory. There is no code to explicitly manage memory, hence no bugs in such code.
• Garbage collected programs are faster to develop and debug, because there's no need for developing, debugging, testing, or maintaining the explicit deallocation code.

Garbage collection is not a panacea. There are some downsides:

• It is not easily predictable when a collection gets run, so the program can arbitrarily pause.
• The time it takes for a collection to run is not bounded. While in practice it is very quick, this cannot be guaranteed.
• All threads other than the collector thread must be halted while the collection is in progress.
• Garbage collectors can keep around some memory that an explicit deallocator would not.
• Garbage collection should be implemented as a basic operating system kernel service. But since it is not, garbage collecting programs must carry around with them the garbage collection implementation. While this can be a shared library, it is still there.

These constraints are addressed by techniques outlined in Memory Management.

How Garbage Collection Works

The GC works by:

1. Stopping all other threads than the thread currently trying to allocate GC memory.
2. ‘Hijacking’ the current thread for GC work.
3. Scanning all ‘root’ memory ranges for pointers into GC allocated memory.
4. Recursively scanning all allocated memory pointed to by roots looking for more pointers into GC allocated memory.
5. Freeing all GC allocated memory that has no active pointers to it and do not need destructors to run.
6. Queueing all unreachable memory that needs destructors to run.
7. Resuming all other threads.
8. Running destructors for all queued memory.
9. Freeing any remaining unreachable memory.
10. Returning the current thread to whatever work it was doing.

Interfacing Garbage Collected Objects With Foreign Code

The garbage collector looks for roots in:

1. the static data segment
2. the stacks and register contents of each thread
3. the TLS (thread-local storage) areas of each thread
4. any roots added by core.memory.GC.addRoot() or core.memory.GC.addRange()

If the only pointer to an object is held outside of these areas, then the collector will miss it and free the memory.

To avoid this from happening, either

• maintain a pointer to the object in an area the collector does scan for pointers;
• add a root where a pointer to the object is stored using core.memory.GC.addRoot() or core.memory.GC.addRange().
• reallocate and copy the object using the foreign code's storage allocator or using the C runtime library's malloc/free.

Pointers and the Garbage Collector

Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data, pointers to objects on the stack, etc. For those pointers, anything that is legal in C can be done with them.

For garbage collected pointers and references, however, there are some restrictions. These restrictions are minor, but they are intended to enable the maximum flexibility in garbage collector design.

Undefined behavior:

• Do not xor pointers with other values, like the xor pointer linked list trick used in C.
• Do not use the xor trick to swap two pointer values.
• Do not store pointers into non-pointer variables using casts and other tricks.

  void* p;
  ...
  int x = cast(int)p;   // error: undefined behavior
  

  The garbage collector does not scan non-pointer fields for GC pointers.
• Do not take advantage of alignment of pointers to store bit flags in the low order bits:

  p = cast(void*)(cast(int)p | 1);  // error: undefined behavior
  

• Do not store into pointers values that may point into the garbage collected heap:

  p = cast(void*)12345678;   // error: undefined behavior
  

  A copying garbage collector may change this value.
• Do not store magic values into pointers, other than null.
• Do not write pointer values out to disk and read them back in again.
• Do not use pointer values to compute a hash function. A copying garbage collector can arbitrarily move objects around in memory, thus invalidating the computed hash value.
• Do not depend on the ordering of pointers:

  if (p1 < p2)  // error: undefined behavior
    ...
  

  since, again, the garbage collector can move objects around in memory.
• Do not add or subtract an offset to a pointer such that the result points outside of the bounds of the garbage collected object originally allocated.

  char* p = new char[10];
  char* q = p + 6; // ok
  q = p + 11;      // error: undefined behavior
  q = p - 1;       // error: undefined behavior
  

• Do not misalign pointers if those pointers may point into the GC heap, such as:

  struct Foo {
  align (1):
    byte b;
    char* p;  // misaligned pointer
  }
  

  Misaligned pointers may be used if the underlying hardware supports them and the pointer is never used to point into the GC heap.
• Do not use byte-by-byte memory copies to copy pointer values. This may result in intermediate conditions where there is not a valid pointer, and if the gc pauses the thread in such a condition, it can corrupt memory. Most implementations of memcpy() will work since the internal implementation of it does the copy in aligned chunks greater than or equal to the pointer size, but since this kind of implementation is not guaranteed by the C standard, use memcpy() only with extreme caution.
• Do not have pointers in a struct instance that point back to the same instance. The trouble with this is if the instance gets moved in memory, the pointer will point back to where it came from, with likely disastrous results.

Things that are reliable and can be done:

• Use a union to share storage with a pointer:

  union U { void* ptr; int value }
  

• A pointer to the start of a garbage collected object need not be maintained if a pointer to the interior of the object exists.

  char[] p = new char[10];
  char[] q = p[3..6];
  // q is enough to hold on to the object, don't need to keep
  // p as well.
  

One can avoid using pointers anyway for most tasks. D provides features rendering most explicit pointer uses obsolete, such as reference objects, dynamic arrays, and garbage collection. Pointers are provided in order to interface successfully with C APIs and for some low level work.

Working with the Garbage Collector

Garbage collection doesn't solve every memory deallocation problem. For example, if a pointer 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 because new stack frames are initialized anyway.

Object Pinning and a Moving Garbage Collector

Although D does not currently use a moving garbage collector, by following the rules listed above one can be implemented. No special action is required to pin objects. A moving collector will only move objects for which there are no ambiguous references, and for which it can update those references. All other objects will be automatically pinned.

D Operations That Involve the Garbage Collector

Some sections of code may need to avoid using the garbage collector. The following constructs may allocate memory using the garbage collector:

• NewExpression
• Array appending
• Array concatenation
• Array literals (except when used to initialize static data)
• Associative array literals
• Any insertion, removal, or lookups in an associative array
• Extracting keys or values from an associative array
• Taking the address of (i.e. making a delegate to) a nested function that accesses variables in an outer scope
• A function literal that accesses variables in an outer scope
• An AssertExpression that fails its condition

References

• Wikipedia
• GC FAQ
• Uniprocessor Garbage Collector Techniques
• Garbage Collection : Algorithms for Automatic Dynamic Memory Management