[gclist] Re: What to say about GC

[Richard Jones]

Tom Lord writes:
>    Richard Jones writes:
>
>    The memory storage requirements of complex programs are extremely
>    difficult to manage correctly by hand.  A single error may lead to
>    indeterminate and inexplicable program crashes.  Worse still, failures
>    are often unrepeatable and may surface only long after the program has
>    been delivered to the customer.  The eradication of memory errors
>    typically consumes a substantial amount of development time.  And yet
>    the answer is relatively easy - garbage collection - removing the
>    clutter of memory management from module interfaces which then frees
>    the programmer to concentrate on the problem at hand rather than
>    low-level book-keeping details.
>
>    [....] This book considers how dynamic memory can be recycled
>    automatically to guarantee error-free memory management.
>
>
>I am a big fan of garbage collection and I'm looking forward to
>seeing Richard Jones' book.
>
>But I also think that the paragraphs quoted above are an exaggeration
>of a sort that can mislead people about garbage collection and set
>them up to be badly disappointed.  This particular exaggeration is
>wide-spread; I'm sure I've passed it along myself.

Much of what Tom writes is sound; I would accept criticism that these
paragraphs are a precis. In fact they are blurb from the back of the book,
which is probably not appropriate to this audience. Blame Friday afternoon...

>Second, the paragraphs above suggest that using a garbage collector
>completely and automatically solves at least the problem of
>prematurely freeing an object.  If garbage collectors never changed or
>needed to be extended and were known to be free of errors and
>completely reliable, the quotes would be right but in fact garbage
>collectors do need to be changed and extended and are prone to hard to
>detect, repeat, and repair bugs.

I do not believe this is a problem for HGC any more than it is a problem
for any other tool. Should we predicate every discussion of every
technique or tool with a disclaimer as to the correctness of its implementation?
Fergus' point that these 

>... are activities which are performed by the garbage
>collector implementor or the programming language implementor.	 That's
>a major advantage of garbage collection: the vast majority of the
>difficult, low-level memory management stuff gets done by a few
>programmers who are experts in that area, and their code is then reused
>by thousands of other programmers who need worry about memory management
>issues only very rarely at most.

is straight to the point.

Tom continues by discussing reference counting:

>To avoid premature freeing, programmers have to prove
>that reference count adjustments are always made when needed and are
>always properly balanced -- this is trivial because it can be
>automated as an extension to the usual behavior of pointer assignment.

Although I believe that RC has its place (for example in distributed systems),
this is an exaggeration. Because RC is so closely interleaved with 
mutator operations, it is error-prone. Adjustments to RCs may be overlooked
--- particularly if the programmer is tempted to optimise out some
operations --- and references may leak to non-RCed pointers.


Richard Jones
<http://www.ukc.ac.uk/computer_science/Html/Jones/>