[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Oct 14 09:19:59 1993 
Subject:GC (was Re: Threaded Interpreted Languages) 
From:jlc (Jonathan Cunningham) 
Volume-ID:931015.04 

Richard Hartman writes
> Actually, no.  I am interested in finding out just what advantages
> GC actually might give me (who have so far had no problems keeping
> track of such things myself) for the performance penalty that is
> usually paid for such systems.  I have not said "GC is worthless",
> I have asked "what is it's worth?".  So far the only answer I have
> ever gotten to this question is "you don't have to keep track of
> your dynamically allocated objects".

I'll come back to this below.
>
> >-environment-. If the decision about what is or is not garbage is taken
> >automatically, then adaptation of a product to market requirements in which
> >what was previously garbage becomes gold is -much- easier.
> 
> This is a separate issue, and headed off in another direction.  From what 
> I understand, the decision made by GC is "can I throw this away yet?" not 
> "should I keep this because someone might want it later?"

I agree this is a digression, but I think the point here is that, if you
change the specs so that some data is needed later, then merely keeping
(a pointer to) it is sufficient to prevent its deletion. I guess if you
write well structured code, you could reply that you only need to comment
out (or #define out) one line of code that calls your routines for
deallocating store. But I reckon that, unless you had anticipated the
need (which violates the presupposition of a change in spec) you would be
lucky to get away with a one line edit.

Returning to your main question: yes - all a GC buys you is that you
don't have to keep track of your dynamically allocated objects. That
is what it is for. So what is its worth?

For an *experienced* programmer, writing most kinds of programs, not
a lot really. Particularly nowadays, where you can allocate quite
complicated data structures as automatic in C++ (rather than on the
heap) and have the compiler dispose of them for you (and also to
create and destroy temporary objects). But even then, a GC is saving
you something: you don't have to think about memory so much, you
can write a few less lines of code to achieve the same purpose. But
even on fairly complex tasks (including many list processing kind
of things) the savings are probably only a few percent - not significant.

For a novice programmer, the savings are much greater: they have to
spend a lot more time thinking about memory (on list processing
kinds of things). Not so much on *writing* code, but on debugging
when they get it wrong: you've probably forgotten, but this kind of
stuff is actually quite complex to get right *for a less experienced
programmer*. At least with a GC they have more chance of getting
something working quickly, although it may run *very* slowly if
the data structures/memory usage is very inefficient - but that is
a separate issue. Perhaps we can also include experienced but less
skilled programmers, ie people who aren't as smart as you are.
We could also include people who are used to programming in an
environment with GC, because they'll need to practise a bit to
acquire the skills to effortlessly write correct code to dispose
of objects - but many of them could learn the skills very quickly.

Incidentally, I would include reference count schemes along with GC
schemes, since reference counting is more limited than GC (circular
structures) and usually carries a bigger run-time overhead. So if
you ever use reference counts, you could be better off with a good
GC scheme (incremental if you need guaranteed response times).

When do I use reference counts (in C++)? Well, I had to do some
fairly complex list-munging in C++ recently, which could be described
as computing the logical conjunction of pairs of propositional formulae
and putting the results
into a normal form. Lots of times. With lots of shared sub-lists.
I wanted to avoid copying sub-lists when sharing was possible
(to save memory) so it would have been *very* difficult to determine
how far down a linked list I could free cells without a reference
count. But I think, in the last three years, that is the only time
I've felt a strong need for a GC. (It's difficult to be sure, because
a lot of my time I've been using Poplog and if you have a GC you
don't need to think about GC, so I'm not sure whether I did anything
in Poplog that involved very hairy store management.)

Cheers,
Jonathan Cunningham
jlc@bmtech.co.uk