Turning off the D garbage collector

Question

I\'m a C++ programmer thats considering using D for a personal project I want to play around with. I was wondering if there\'s a way to completely disable the garbage collector

Answer 1

To turn off the GC in D2:

import core.memory;

void main(string[] args) {
    GC.disable;
    // Do stuff.
}

If using D1/Phobos:

import std.gc;

void main(char[][] args) {
    std.gc.disable;
    // Do stuff.
}

In D1/Tango:

import tango.core.Memory;

void main(char[][] args) {
    GC.disable;
    // Do stuff.
}

The GC can be reenabled similarly by calling GC.enable (D2 or D1/Tango) or std.gc.enable (D1/Phobos). These can be done at any point in a program. Internally, a counter is used, and to actually reenable GC, you must call enable() once for every time disable() was called.

Here are some things not to do with GC disabled, because they will cause memory leaks:

1. Do not use the array append ( ~= ) operator, or use the .length property to enlarge an array that has already been allocated. These rely on GC to free the old array if it has to be reallocated, since there may be aliasing to it somewhere else in the program.
2. Do not use builtin associative arrays. The only way to free these is by GC.
3. Most of Phobos and, I believe, Tango, were designed with the assumption that garbage collection is present. Functions in these libraries may leak memory horribly if used w/o GC.
4. Do not use D2 closures with GC disabled. (Not that you would anyway, for a game.)

That said, while D is designed to be usable with the GC disabled in a few critical pieces of code (the kind of critical pieces where real time constraints exist and you probably shouldn't be using any form of malloc not explicitly designed for real time computing anyhow), it was largely designed with the assumption that GC would be present. In your case, you can still use GC for all of the initialization stuff, etc. and only disable it when you hit the part of your game that actually needs to be real time.

As a side note, GC and manual memory management can coexist in D, and in practice, when optimizing code, manually deleting some large objects with trivial lifetimes can result in significant speedups. This can be done similarly to C++, using a delete statement, and is safe to do even if the GC is enabled. When you don't have real time constraints, this gives you most of the benefits of GC with most of the performance of manual memory management.