Getting completely (I mean ENTIRELY) rid off GC

[Sean Kelly via Digitalmars-d]

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.