GC, the simple solution

[Kevin Bealer]

In article <e60vmu$1b6t$1 at digitaldaemon.com>, Walter Bright says...
>
..
>>>>> 9) Ref counting does not eliminated latency problems, it just reduces
>>>>> them.
>>>> Where do you mean is the latency with RC? The collecting work is done in
>>>> the smallest pieces all the time. Only the allocation of new memory
>>>> needs an unbound time to complete.
>>> That's the same with gc. Only upon an allocation is the time unbound.
>> And additional the time is unbound for the GC fullcollect...
>
>The collector only runs during an allocation request - which means you 
>can completely control when a collection can happen.

Correct me if I'm wrong, but while this is true for M + S, doesn't RC /kind of/
have the opposite problem?  In refcounting systems, allocation would be mostly
predictable, a la malloc, but dereferences can trigger a long chain of other
dereferences.

I say 'kind of' because it is more deterministic than GC - you can always dig
deeper to see what is going to be freed by a given dereference.

For instance, if you are the last person to let go of a hash table, you have to
wait for the whole thing to unravel, along with any objects stored inside.

I guess a real-time RC implementation could be made by keeping a 'recycling bin'
and only taking apart N objects at a time, i.e. incremental freeing.  This would
un-guarantee the prompt running of destructors though (which seems to be one of
the big rationales for RC in D, right, at least for non-memory objects?)

Kevin