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