Getting completely (I mean ENTIRELY) rid off GC

[via Digitalmars-d]

On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov 
wrote:
> Hello everyone! Being a C/C++ programmer I don't understand, 
> why such language as D (system programming language) 
> implemented garbage collector as a core feature, not as 
> additional optional module or library.

I can enlighten you ;-) The reason is safety. Past experience 
(especially with C & C++) has shown that manual memory management 
is easy to get wrong. Besides, certain features would not easily 
be possible without it (dynamic arrays, closures).

> I and many other C/C++ programmers prefer to control things 
> manually and use flexible allocation schemes that suitable for 
> concrete situations. When every nanosecond matters, this is the 
> only option, at least nowadays.
>
> So this particular thing stops many of us from using D. When 
> you can abandon performance, you usually choose Java (Scala) or 
> C# because of their rich support and libraries. And the 
> opposite matter is when you need high performance. In this case 
> there is almost nothing to choose from. C/C++11 now looks not 
> so bad.
>
> And I think of idea of complete extraction of GC from D. For 
> this to achieve, I suppose, I have to dig deeply into D 
> compiler and also correct/re-implement many things in modules, 
> so this ends up with almost new version of D.
>
> I would like to hear your suggestions and some basic 
> instructions. Maybe this is not a good idea at all or it will 
> be very hard to realize.

I don't think it is necessary to remove the GC completely. It can 
only interfere with your program in three situations:

1) When you allocate and run out of memory, the GC will first try 
to release some unneeded memory before requesting more from the 
OS. If you don't allocate, anything in a performance critical 
section of your program, the GC will never run.
2) (Actually a consequence of 1) When the GC runs, it stops all 
threads, including those that never allocate.
3) When you call it manually.

For 1), there is the @nogc attribute. Any function marked with 
this attribute is guaranteed to never allocate on the GC heap, 
including via any other functions it calls. If you write `void 
main() @nogc`, your entire program will be GC-less. This 
attribute has only been introduced in the latest release, and 
some parts of the standard library cannot be used with it yet.

For 2), you can call `GC.disable()` and `GC.enable()` to switch 
the GC on/off temporarily. You can still allocate memory, but the 
GC will not run.

For 3): Do it when you can afford the latency, for example 
between frames, or when you are not in a performance critical 
section of your program. Right now, it is not anytime capable, 
which means you cannot give it a deadline until that it either 
has to finish, or abort the current operation. This would be an 
interesting enhancement.

As for manual memory management, Andrei is currently working on 
an allocator library: 
http://erdani.com/d/phobos-prerelease/std_allocator.html