Garbage Collection in D

D ships with a built-in garbage collector that automatically manages memory for class instances allocated with new, dynamic array growth, associative arrays, and closures that capture variables by reference. The default D GC is a conservative, mark-and-sweep, stop-the-world collector: conservative means it scans memory (including the stack and CPU registers) for bit patterns that look like they could be pointers into the GC heap, without requiring precise type information at every allocation, and stop-the-world means that during a collection cycle all other threads managed by the runtime are paused while the collector marks reachable objects and sweeps the rest. This design trades some memory precision and pause-time predictability for simplicity and safety: you rarely need to think about freeing memory explicitly for ordinary D code, which is why idiomatic D leans on the GC by default and only opts out selectively where determinism or latency matters.

The core.memory module exposes the GC struct with static functions for direct control: GC.collect() forces a full collection cycle immediately rather than waiting for the runtime to decide one is needed, GC.disable() and GC.enable() toggle whether automatic collections are allowed to run at all (allocations still succeed while disabled, they just accumulate without being collected), and GC.stats() returns a snapshot with usedSize and freeSize letting you inspect heap usage for diagnostics or tests. When your program holds memory that the GC did not allocate — for example a block obtained from malloc that you want scanned for embedded D references, or memory-mapped external memory — you can register it with GC.addRange(ptr, size) so the collector includes it when scanning for live pointers, and unregister it later with GC.removeRange(ptr) once it's no longer relevant. These controls are mostly used for tuning latency-sensitive code paths (like temporarily disabling collection during a real-time audio callback) or for writing precise unit tests that assert on allocation counts.

The @nogc attribute can be attached to a function signature, void process() @nogc { ... }, and the compiler then statically enforces that the function's body performs no operation that could trigger a GC allocation — no new for classes, no array literal that allocates, no closure capture that needs heap storage — flagging a compile error if it does. This is valuable in real-time or latency-sensitive code (audio processing, game loops, signal handlers) where an unpredictable GC pause is unacceptable; @nogc functions typically rely on stack-allocated structs, static arrays, or manually managed memory instead. Beyond @nogc, general techniques for reducing GC pressure include using std.array's reserve to pre-size a dynamic array before a loop of appends (avoiding repeated reallocation), preferring structs over classes for short-lived, non-polymorphic values, and reusing buffers across iterations instead of allocating a fresh array on every call.

Because the D GC scans conservatively, it can occasionally treat an ordinary integer value on the stack that happens to look like a valid heap pointer as a genuine reference, keeping the object it 'points to' alive longer than necessary — this is called a false pointer, and while it cannot cause a use-after-free, it can cause memory that should have been reclaimed to leak for the remainder of the program (or until the false pointer's stack slot is overwritten). Stop-the-world pauses scale with the number of live objects and heap size, so a program with a very large live object graph can experience noticeably longer pauses at collection time, which matters for interactive applications and real-time systems even though it is rarely a problem for typical batch or server workloads. Finally, because class destructors run at GC-determined times, code that assumes a resource wrapped in a class (a file handle, a socket) will be released promptly when the last reference goes out of scope is simply wrong in D — that assumption holds for structs with deterministic destructors, not for GC-managed classes, and mixing up the two is one of the most common sources of resource-leak bugs for programmers coming from RAII-heavy languages.