GC, the simple solution

Lars Ivar Igesund larsivar at igesund.net
Mon Jun 5 02:04:58 PDT 2006


Daniel Keep wrote:

> 
> 
> Frank Benoit wrote:
>> In nearly every other GC implementation you will need also a read or
>> write barrier. With reference counting you have a write barriere.
>> 
>> Yes, the unprecise, non-incremental, "Stop-the-world", non-concurrent,
>> non-generational, conservative Phobos GC implementation is an exception.
>> 
>> But a write barrier alone doesn't make ref counting ridiculous. Well you
>> are right, it is not the solution for all and everything, but I think a
>> big step in the right direction. And mark&sweep GC should be the option.
> 
> I guess we'll just have to disagree, then :)
> 
> Like I said before, I think the current GC should be the default since,
> even if it's not the best in terms of latency, it's the *safest*.
> There's no need for someone coding under it to worry about things like
> cycles, etc.  

Well, actually, the current GC is kinda bad with cycles. Try to make a
circular linked list where you keep a single additional reference to one of
the elements. Then remove the reference and collect. In theory this memory
should now "just" be lost/leaked, but you might also experience crashes. I
think Chris Miller had some interesting revelations on the subject.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi



More information about the Digitalmars-d mailing list