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
