Getting completely (I mean ENTIRELY) rid off GC

[via Digitalmars-d]

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.

But this is a very specialized solution and requires a lot
discipline, of course.