On Thursday, 11 September 2014 at 19:14:42 UTC, Marc Schütz wrote:
On Thursday, 11 September 2014 at 16:02:31 UTC, Sean Kelly
wrote:
On Thursday, 11 September 2014 at 13:16:07 UTC, Marc Schütz
wrote:
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).
GC is hugely important for concurrent programming as well.
Many of the more powerful techniques are basically impossible
without garbage collection.
There is an interesting alternative that the Linux kernel uses,
called RCU (read-copy-update). They have a convention that
references to RCU managed data must not be held (= borrowed by
kernel threads as local pointers) across certain events,
especially context switches. Thus, when a thread modifies an RCU
data structure, say a linked list, and wants to remove an
element from it, it unlinks it and tells RCU to release the
element's
memory "later". The RCU infrastructure will then release it once
all processors on the system have gone through a context switch,
at which point there is a guarantee that no thread can hold a
reference to it anymore.
Yes, RCU is one approach I was thinking of. The mechanism that
detects when to collect the memory is basically a garbage
collector.
