More radical ideas about gc and reference counting

[Benjamin Thaut via Digitalmars-d]

Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
>
>> The next sentence goes on to list the advantages of RC (issues we have
>> wrestled with, like destructors), and then goes on to say the recent
>> awesome RC is within 10% of "the fastest tracing collectors".
>> Are you suggesting that D's GC is among 'the fastest tracing
>> collectors'? Is such a GC possible in D?
>
> I believe it is.
>

While it might be possible to implement a good GC in D it would require 
major changes in the language and its librariers. In my opinion it would 
be way more work to implement a propper GC than to implement ARC.

Every state of the art GC requires percise knowdelge of _all_ pointers. 
And thats exactly what we currently don't have in D.

Just to list a few issues with implementing this in D:

1) Calling C-Functions would require some kind of pinning API for the 
GC. But functions with C-calling convections are used ecessivly in 
druntime. So a lot of uneccessary pinning would happen within d-runtime 
just because of all the c-function hacks around the module system.

2) Most modern GC algorithms require write-barriers for pointers which 
are on the heap. This is a major problem for D, because structs can be 
both on the stack and on the heap. So if you call a method of a struct, 
the compiler can not know if the write barriers are actually neccessary 
(for heap based structs) or unneccssary (for stack based structs, e.g. 
inside classes).

3) Generating percise information of the location of pointers on the 
stack is going to be a major effort, because of structs, unions, 
exception handling and Ds ability to move struct instances freely around 
when dealing with exceptions.

4) As soon as you want to be fully percise you can not halt threads in 
random points, you will need to generate GC points on which the 
execution can be safely halted. This is going to require major effort 
again if it should be done efficiently.

5) As Ds strings are immutable(char)[] they can not be allocated on a 
thread local pool, because they must be freely shareable between 
threads, and there is currently no way to detect via the type system 
whean a immutable(char)[] is shared with another thread. So we would 
need to design a system were the sharing of memory blocks would be 
detected, so we could properly implement thread local GC pools. The same 
issue applies to __gshared.

Honenstly, D doesn't currently have any GC support at all. The only GC 
support we have is that the GC knows all threads and can halt them. And 
D knows which function to call, to destroy class objects. So basically 
we have the same level of GC support as C or C++. You could just use the 
Boem GC, plug it into C or C++ and have a GC that is as good as the D one.

So having a good GC in 5 years or having ARC in 1 year isn't a decision 
that is that hard for me.

Kind Regards
Benjamin Thaut