Re: Storage management, was Compiler writers will love this language

"Rodney M. Bates" <rodney.bates@wichita.edu> writes:
|> Eric wrote:
|> > One of the reasons I
|> > really fancy reference-counting is its low overhead, but I suspect
|> > that with a few adjustments to the algorithm, one can add in logic
|> > that will detect circular links during deallocation.
|>
|> Actually, as I recall, reference counting has much higher overhead
|> than all forms periodic tracing GC. Intuitively, it's because it has
|> to keep track of referenceability all the time, whereas the periodic
|> collectors can forget about it for a time, then recompute what is
|> referenceable only occasionally.


That is deceptive, and many of the books on garbage collection
approach propaganda on the issue. I agree with Lex Spoon here.


Reference counting is very cheap for some purposes. For example,
there are many where allocation and setting up permanent pointers is
rare, but known temporary (scope checked) pointers are common. For
example, many data structures in operating systems - and they often
use reference counting as the primary method.


Secondarily, it ignores the software engineering aspects, and even
simple debugging. If you are to enable any useful debugging of memory
allocation, you virtually have to maintain enough state that reference
counting comes for free. But who provides facilities for debugging
applications in the field any longer?


|> Reference counting can operate right down to zero "headroom", i.e.
|> available space, whereas the others generally need a certain amount of
|> headroom.


Generally, yes. There are forms of reference counting that can't,
of course.


|> Short of resorting to some kind of hybrid with a tracing algorithm,
|> I don't believe anyone has ever fixed the cyclic graph problem with
|> reference-counting.


As it is theoretically impossible to fix, that seems likely :-)




Regards,
Nick Maclaren.

Return to the comp.compilers page.
Search the comp.compilers archives again.