Mac Apps That Use Garbage Collection Must Move to ARC

Benjamin Thaut via Digitalmars-d digitalmars-d at puremagic.com
Sun Feb 22 04:55:17 PST 2015


Am 22.02.2015 um 10:48 schrieb Russel Winder via Digitalmars-d:
> On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d
> wrote:
>> Am 22.02.2015 um 03:13 schrieb Walter Bright:
>>>
>>> Nobody thinks GC is suitable for hard realtime.
>>
>> I think you should know manu good enough by now that you know he is not
>> talking about hard realtime but soft realtime instead. (e.g. games)
>> There are GCs which handle this situation pretty well but D's GC is not
>> one of them.
>
> If the D GC really is quite so bad, why hasn't a cabal formed to create
> a new GC that is precise, fast and efficient?

There have been countless dicussions about D's GC and how bad it is, and 
how to improve it. But it always turns out that it would be a ton of 
work or someone doesn't like the consequences. The key points always are:

1) We need full percise pointer discovery, even for pointers on the stack.
2) We need write barriers.

1) Is a really complex task for a language like D. There is a reason why 
java has so a small feature set.
2) For some reason nobody likes write barries because the general fear 
is, that they will cost performance, so it was decided to not implement 
them. (Without actually measuring performance impact vs GC improvement)

The problem is that, to implement a non stop-the-world-GC you need 2) 
and to implement a GC which is on par with Java or C# you need 1).

So until there is no implementation for any of the both mentioned 
points, there will be no better GC in D. You can fake 2) with fork on 
linux, thats what the CDGC did (see the DConf talk). This works because 
fork has copy on write semantics, but there is no equivalent on Windows. 
Experiments by Rainer Schuetze to implement similar copy on write 
semantics on Windows have shown to have major overhead which is most 
likely even worse then implementing write barries themselfs. Experiments 
implementing a Heap-percise GC, again by Rainer Schuetze, have schon 
that percicse heap scanning is slower compared to impercise scanning.

In my opinion the key problem is, that D was designed in a way that 
requires a GC but D was not designed in a way to propperly support a GC. 
(shared, immutable and other things basically prevent thread local pools).

Kind Regards
Benjamin




More information about the Digitalmars-d mailing list