D Programming Language

Why D?

Show off D


Garbage Collection

Example code showing GCStats:

import std.stdio;

extern (C)
    void gc_stats(GCStats* stats) nothrow;

struct GCStats
    size_t poolsize;        // total size of pool
    size_t usedsize;        // bytes allocated
    size_t freeblocks;      // number of blocks marked FREE
    size_t freelistsize;    // total of memory on free lists
    size_t pageblocks;      // number of blocks marked PAGE

void main()
    GCStats stats;
    auto p = new byte[200];
    p = new byte[1000];
    p = new byte[10000];

To turn on garbage collection profiling

$ max_column_sum_by_key_v1 --DRT-gcopt=profile:1 ngrams.tsv 1 2
max_key: 2006 sum: 22569013
        Number of collections:  132
        Grand total GC time:  246 milliseconds
GC summary:   35 MB,  132 GC  246 ms

Summary of GC discussion

See June 2016 discussion on the Garbage collector

Memory allocations are /always/ expensive. Higher level languages like Java have the benefit of using pools and optimizing for this usage pattern, D does and will never have this. Keep in mind an allocation = usage of malloc + write to returned pointer. – rikki c.

The point is, D doesn’t have to have a GC. Not using it is way easier than in most other languages because all the tools to help you profile it and avoid it are provided by the compiler. Go without a good GC is a dead language. D without a good GC is just not as good as it could be. And btw we’re generally faster than Go ;-) The point is: while a better GC is a work in progress we’ll never have a GC that can fit all needs, but it’s not as critical as it is in Go or in C# because we provide other ways to manage memory when limitations arise. – cym13

“Has anyone thought about taking GC from .NET and reusing it in D?”

One significant point has been already mentioned: cost of write barriers. I’d like to mention another factor: .NET GC is a copying one, it moves data around. One good feature of current D is it never moves data, so you can very easily call C and C++ code and pass pointers to your buffers and stuff and C/C++ code just takes these pointers and works with them as usual. No pinning, no marshaling, zero overhead. If you take a moving GC like .NET’s, you immediately make all C/C++ interaction much harder, now you need to worry about pinning stuff or copying “managed” data to “unmanaged” memory and back. This is all costly both in terms of CPU cycles and of programmer cycles. You’ll need “FFI”, what most other GC-ed languages have to have, and D doesn’t. –thedeemon

Precise Garbage Collector

GSoC project

It is essentially in a similar state that it was when Rainer presented it at DConf2013. The version in the pull request is not different from the one Rainer presented at all. It’s actually the same one, just updated with what has been changed in druntime recently and my attempts at making the marking phase faster.

Meta programming3





Range based programming

Profiling / performance

D run time


C/C++ binding

Lexing and parsing

Another option is to use a lexer/state machine generator. Ragel supports D and Rust (as of the not-quite-released v7) as target languages. HN

Memory safety

Documenting D code

Higher level programming










Read code


Contributing to D development

Software written in D

Developing and distributing D software


User experience


For some reason, many D programmers have this “collection of D libraries”, which is interesting in the sense that more than one developer has found it just easy to write their own library to do X…

In addition to those of CWEB:

Inspired from CWEB: