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, and what the risks are of doing so.

I know I can manage my own memory by overriding new and delete to use malloc and free, but if I did that I'd rather the garbage collector not run at all.

Answer 1

If you want to use malloc and free use std.c.stdlib. GC will never touch these. std.gc has all the stuff you will need for memory management including disable().

GC isn't a bad thing though. Most if not nearly all libraries in D will have somewhere in the code where memory is not explicitly deleted so it won't make you a hero to have it allways off but ok if you have some critical performance requirement.

GC makes everything a lot more productive like array slicing and creating new objects in parameters without having the caller store a reference anywhere to them. Good code is a lot less of it and with GC code becomes a lot smaller.

Answer 2

The GC can be removed and replaced with a simple wrapper around malloc/free.

Answer 3

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.

Answer 4

I was reading about D language and I found this in the specs that seems new in D:

40. Better C

-betterC is a command-line flag for dmd, which restricts the compiler's support of certain runtime features. Notably, D programs or libraries compiled with betterC aren't linked with Druntime. The use of compile-time features is not restricted in any way. https://dlang.org/spec/betterc.html

One of the consequence of using this command-line flag is to disable GC and language features relaying on it.

40.1 Consequences

As no Druntime is available, many D features won't work. For example:

• Garbage Collection
• Thread-local storage
• TypeInfo and ModuleInfo
• Classes
• Built-in threading (e.g. core.thread)
• Dynamic arrays (but not slices) and associative arrays
• Exceptions
• switch with strings
• final switch
• synchronized and core.sync
• Static module constructors or deconstructors
• Struct deconstructors
• unittest (testing can be as usual with the -betterC flag)

see also https://dlang.org/blog/2017/08/23/d-as-a-better-c/