GC, the simple solution

[Daniel Keep]

Sorry for the late (and short) reply: exams breathing down my neck and
all :)

Larry Evans wrote:
> On 06/04/2006 05:40 AM, Daniel Keep wrote:
> 
>> "GC, the simple solution"
> 
> [snip]
> 
>> * inability to free cycles
>> * inability to even *run* destructors where cycles are involved, because
>> there is no order in which they can logically be executed and still be
> valid
> 
> 
> I think someone else in the thread mentioned this as a programmer error.
> However, assuming the programmer intended this, then this programmer
> must expect that the MS GC would break the cycle somewhere before
> calling the destructors and he must not care where the cycle was
> broken, because otherwise he would have used a weak pointer
> to close the cycle where he wanted the break to occur.
> 
> Anyway, code for doing this GC breaking of cycles in RC
> is at:
> 
>   http://tinyurl.com/reuzl
> 
> See code after comment:
> 
>  *  Breaks all arcs in cycle_arcs.
> 
> As mentioned in the code comments, this is Christopher's
> method for collecting cycles and suffers a delay since it
> keeps all smart ptrs in a list and processes the entire list.
> Other methods don't keep this list but do a local mark-sweep
> at each rc decrement with obvious time penalties.  A compromise
> just uses a queue which, when it reaches a certain size,
> plays the same role as Christopher's list of all smart pointers.
> 
>>
>> Those last two are the main problem with reference counting, along with
>> the others and slightly added complexity in the compiler.
>>
>> Python, however, does not suffer the cycle problem.  Know why?
>>
>> Because they have a *mark & sweep* garbage collector to clean up the
> cycles.
> 
> Then it must not automatically call destructors since then it would
> suffer the 2nd problem above.

I haven't read the above link since I really don't need to be distracted
any more than I already am at the moment.  I'll read that link later on
once I'm not quite so swamped :)

However, I will say this: if you have a cycle in Python, it will clean
it up normally PROVIDED destructors are not involved.  If they are, then
it just moves the whole cycle to a dead object list, since there is no
safe way to break the cycle.  At that point, it's up to the programmer
to deal with it.

> 
>>
> [snip]
> 
>> As it stands, you can implement reference counting yourself: you just
>> need to write an allocator, and call the incref and decref functions
>> manually.  However, I do think that having built-in *support* for
>> Reference counting would be fantastic.  The less that stuff like this is
>> left in the hands of the programmer, the better.
> 
> 
> Smart pointers would be a great help here, but since
> D doesn't allow user definition of the assignment operator:
> 
>   http://www.digitalmars.com/d/archives/digitalmars/D/learn/984.html
> 
> that's not easy.  I'm a newbie, so what's the best way to implement
> something like a smart pointer without having to manually:
> 
>   increment rc1;
>   decrement rc2;
>   assign the pointer to its target location;

Not really, sorry.  Your best bet might be with a preprocessor.  I've
had plans to write an AST-based preprocessor for a while, but that's off
in the far, far future.  Maybe give Build 3.0 a look?  In that case,
you'd want to write a macro like:

    rc2 #= rc1;
==>
    (rc1).incref(); (rc2).decref(); rc2 = (rc1);

Again, sorry for the terse reply.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/