hartman@ulogic.UUCP (Richard M. Hartman) writes:
> Date: 12 Oct 93 18:08:21 GMT
>
> In article <CEL0yG.6q8@dcs.glasgow.ac.uk> pop@dcs.glasgow.ac.uk (Robin Popplestone) writes:
> >|> >Steve Knight who writes applications for Hewlett Packard reckons that, for
> >|> >a given effort, he can write a POP-11 program for many applications that
> >|> >runs twice as fast as the equivalent C. Being able to use appropriate
> >|> >data-structures for the -problem-, knowing that he does not have to worry
> >|> >about reclaiming them, a particularly serious problem in an interactive
> >|> >program that may run ad infinitem, slowly clogging up its virtual memory
> >> >as
> >|> >it does.
> >|>
> >|> I have yet to be convinced that garbage collection is a requirement
> >|> for efficient programming. I have never found it difficult to decide
> >|> when I am done with an object and free() it. Perhaps if you could
> >|> describe a situation where automatic GC is a requirement, and not merely
> >|> a convenience it would help me to understand.
> >
> >
> >Are we getting into one of these "real programmers" arguments here. "Real
> >programmers don't use floating point - they write their fixed point routines
> >in assembly code and ought to know the range of the quantities they are
> >computing with". (Maybe they should...???)
>
> 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 have never found this to
> be problematic -- thus never seen any actual ADVANTAGE to be had
> from using GC. I'm just trying to see if someone else can give
> me a good reason why GC would be better (and worth the performance
> hit) than doing it myself.
If your applications are such that you can always confidently tell
(a) that you are never releasing memory that is still in use, and
(b) never retaining memory that you no longer can or need to use
or at least never doing this to a degree that will degrade
performance,
then there is no benefit in using a garbage collector. Different
tools are needed for different purposes.
There are situations where it is particularly difficult to achieve
(a) and (b). One sort of example is the case where a complex linked
structure S is created by a process P1 and then made available to a
collection of other processes P2, P3, P4, ... either in succession
or interleaved, where these processes are capable of adding to S,
replacing components in S, adding or removing links in S, and saving
parts of of S in structures that are private to the process.
An example might be a sentence analysing process where a first
draft parse tree is passed to various sub-processes that attempt
separately to resolve different kinds of ambiguities, make
inferences, correct erroneous interpretations, etc.
Another example might be a planning process that creates complex
draft plans that are modified, criticised, recorded etc. by other
processes.
If the processes P1, P2, P3, etc. are all pretty complex, and
designed and implemented by different groups of people and liable to
continuing development, then it could be difficult to ensure that
memory is released when it should be and only when it should be. One
way to do this that avoids a full sweeping garbage collection
process is to use reference counts, as someone mentioned, though I
suspect this could have a performance overhead as every assignment
or replacement of a pointer would require a change to a reference
counter. Moreover I suspect that it would still be possible to leave
loops that only a GC could detect (A points to B and B points to A,
and nothing else points to either, so they are both really garbage,
but have non-zero reference counts.)
I suspect that when such systems become quite complex, the
development costs involved in making absolutely sure that store
management involves neither memory leaks nor memory corruption due
to premature deallocation, could outweigh the cost savings in having
a more efficient run time system.
I should also say that many people have a jaundiced view of garbage
collectors because they have experienced only very slow garbage
collectors.
I do all my computing work inside the Poplog editor VED, including
reading and sending mail, reading and post news, preparing latex
files, etc. and there must be quite a lot of garbage collections
because I can use the same VED process for days. Typical process
sizes can vary between about 2 megabytes to 8 or 10, and I turn over
quite a lot of memory because I read and write lots of files,
including occasionally reading in very long online documentation
files to search for some information, after which I discard the
files.
I have to say that I am *NEVER* aware of garbage collections,
because they are so fast, typically taking only a fraction of a
second. I mainly work using X, and logged through to a reasonably
fast shared SPARCServer (SS 672 with two processors), with quite a
lot of memory (124 Mbytes) so that there is rarely any need for
paging and swapping, which can slow down GC enormously. Sometimes I
use a 24Mbyte or 32 Mbyte sparcstation instead (IPC or IPX), and
even then I don't notice garbage collections unless I switch on GC
tracing. (The Poplog GC mechanism was implemented by John Gibson at
Sussex University, who seems to have done a particularly good job,
including providing the option of a copying or a non-copying garbage
collector, and allowing the heap to have holes containing
non-relocatable items, e.g. C datastructures. It's also possible to
reduce the time spent in GCs by "locking" part of the heap, e.g.
after you have compiled lots of functions that you know will never
be garbage.
Besides being very fast, the GCs can be made to occur less often by
allocating more heap space, which is getting cheaper and cheaper all
the time.
However, I have used other unmentionable AI development environments
where a garbage collection is a much more noticeable event, and I
suspect that such unpleasant experiences have coloured the computing
community's general view of garbage collection.
Aaron
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
|