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

nmm1@cus.cam.ac.uk (Nick Maclaren)
13 Jul 2003 23:03:23 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Compiler writers will love this language ericmuttta@email.com (2003-06-05)
Re: Compiler writers will love this language mwotton@cse.unsw.edu.au (2003-06-08)
Re: Compiler writers will love this language ericmuttta@email.com (2003-06-20)
Re: Compiler writers will love this language mwotton@cse.unsw.edu.au (2003-06-22)
Re: Compiler writers will love this language ericmuttta@email.com (2003-07-02)
Re: Storage management, was Compiler writers will love this language rodney.bates@wichita.edu (Rodney M. Bates) (2003-07-04)
Re: Storage management, was Compiler writers will love this language nmm1@cus.cam.ac.uk (2003-07-13)
Re: Storage management, was Compiler writers will love this language mwotton@cse.unsw.edu.au (2003-07-13)
Re: Storage management, was Compiler writers will love this language mwotton@cse.unsw.edu.au (2003-07-13)
Re: Storage management, was Compiler writers will love this langua monnier+comp.compilers/news/@cs-www.cs.yale.edu (Stefan Monnier) (2003-07-17)
Re: Storage management, was Compiler writers will love this langua monnier+comp.compilers/news/@cs-www.cs.yale.edu (Stefan Monnier) (2003-07-17)
Re: Storage management, was Compiler writers will love this language haberg@matematik.su.se (2003-07-17)
Re: Storage management, was Compiler writers will love this language waxlex@yahoo.co.uk (ikhnos) (2003-07-21)
[2 later articles]
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 13 Jul 2003 23:03:23 -0400
Organization: University of Cambridge, England
References: 03-05-211 03-06-015 03-06-054 03-06-057 03-06-078 03-06-106 03-07-023 03-07-044
Keywords: storage
Posted-Date: 13 Jul 2003 23:03:23 EDT

"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.


Post a followup to this message

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