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
