<div dir="ltr">So let's talk about garbage collection, and practical strategies to avoid allocation.<div><br></div><div>GC related discussions come up basically every day, perhaps multiple times a day on IRC, and the recent reddit 2.063 release thread is dominated by C++ programmers who are keenly interested in D, but are scared by the GC.</div>
<div>I can say with confidence, as someone who has gone out on a limb and actually invested a lot of time and energy in D, I'm as nervous (or more so) as they are, and feel their turmoil deeply!<br></div><div><br></div>
<div><div style>So where are we?</div><div style><br></div><div style>I can only speak from my industry's perspective. As I see it, we are here:</div><div style> - Stopping the world is unacceptable<br></div><div style>
 - Scanning the whole heap is costly</div><div style> - Also seems extremely wasteful to scan the whole heap when the overall temporal stability of a realtime heap is extremely high (just a few temps allocated frome-to-frame on average, and mostly on the stack!)</div>
<div style> - GC runs at unpredictable moments</div><div style> - GC collection cycles become more and more frequent the less unallocated memory overhead you have. Hint: video games usually run within kb of the systems available memory. How often will full heap-scanning collections be issued to collect a couple of transient/temporary allocations when there is only a few kb free memory? Conceivably, more than once per frame...</div>
<div style> - In a low-free-memory environment, what is the cumulative effect of fragmentation? Can this be measured, or will it be a nasty surprise 2 months from shipping a 20-million dollar project? (Hint: a discovery of this sort could very well ruin a project and destroy a company)</div>
<div style><br></div><div style>Basically nobody will have experienced these issues to their fullest extent on a PC with plentiful memory. But they must be considered if the audience still stuck in C++ is to take D seriously (who I predict are D's greatest potential user-base).</div>
</div><div style><br></div><div style>While I do think a sufficiently advanced GC might satisfy the realtime environment, the more I think about it, the more I am thinking a GC is not applicable to the embedded (or memory limited) environment.</div>
<div style><br></div><div style>So what options exist?</div><div style><br></div><div style>I'm thinking more and more that I like the idea of a ref-counting GC.</div><div style>People argue that managing ref-counts may be slower, perhaps true, it requires a small amount of localised overhead, but if allocation frequency is low, it shouldn't be much.</div>
<div style>I think the key advantages though are:</div><div style> - determinism, memory will be immediately freed (or perhaps deferred by a small but predictable amount of time, let's say, 1 frame)</div><div style> - elimination of full-heap scans which takes the most time</div>
<div style> - the refcount table is self-contained, won't destroy the dcache like a heap scan</div><div style> - less tendency to fragment, since transient allocations can come into and leave existence before something else allocates beside it</div>
<div style><br></div><div style>But this is only part of the problem.</div><div style>Naturally, the fastest allocation is the one that never happened.<br></div><div style>So an equally, or even more important aspect of the puzzle is offering clearly documented advice, and convenient syntax/patterns on how to avoid allocation in general.</div>
<div style>It should be made EASY to avoid allocation. This way people will tend to do it by habit, further alleviating the problem.</div><div style><br></div><div style>I've made the case that libraries should avoid surprise allocations at all costs. Maybe this leads back to @nogc conversations (a concept I'm not personally sold on), but something needs to be done, and best-practises/conventions need to be defined.</div>
<div style><br></div><div style><div>So I'd go so far as to say, perhaps these 2 points should be considered as key goals for 2.064?</div><div style>  * find a solution for deterministic embedded garbage collection</div>
<div style>  * decide some realistic best-practises/conventions for reliably (and conveniently!) avoiding allocations</div><div><br></div><div>Showing progress on these will show real progress on D for ex-C++ users. In my time using D, there has been exactly ZERO progress on the GC issue, which is discouraging to say the least, perhaps even kinda scary. (fortunately, people are thinking about it, and there were 2 great talks at dconf, but I don't think either address the specific issues I raise)<br>
</div><div><br></div></div><div style>Discuss... (or perhaps, "destroooy")</div></div>