Path: utzoo!utgpu!watserv1!watmath!att!cbnewsl!psrc
From: psrc@cbnewsl.att.com (Paul S. R. Chisholm)
Newsgroups: comp.object
Subject: Re: What is Objective C?
Summary: programmer-controlled memory management vs. garbage collection
Message-ID: <1990Sep11.030523.19830@cbnewsl.att.com>
Date: 11 Sep 90 03:05:23 GMT
References: <3864@bingvaxu.cc.binghamton.edu> <77500056@m.cs.uiuc.edu>
Organization: AT&T Bell Laboratories
Lines: 54

In a previous article, I wrote:
> So . . . will a program that, by the language definition, must do
> garbage collection, run as quickly as a program where the "user" (the
> programmer in the language in question) must manage memory?  Probably
> not, unless the language implementor has done a terrific job, and the
> "user" has botched it.

Looking back, this was a tad small.  Times have changed, and most of
the applications I write could probably run with garbage collection.
That would would save me time in coding, and it might save me time in
debugging (if I had a memory leak or dereferenced a dangling pointer).

But if I was writing an operating system, or a real time application,
the (unpredictable) overhead of garbage collection might not be
acceptable.  Then, I'd be willing to pay the (programmer) effort, and
manage memory better than a garbage collector could.

Somebody (Lawrence K-something, I think) said that good garbage
collectors are hard to beat, unless you use a fixed-size memory pool or
some such trick.  Funny, it sounded as if he was disagreeing with me.
That's *exactly* the kind of technique needed.

In article <77500056@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu writes:
> My experience with C++ is that memory management takes a lot of CPU
> time.  We use reference counting, and have to lock objects before
> changing their reference count (we are using a multiprocessor).  Not
> only is this time-consuming for the programmer to get right, it is
> time-consuming for the computer to execute.

Reference counting is *slower* than garbage collection (see the
Smalltalk implementation book).  This is *not* what an efficiency-
paranoid C++ programmer must do.

> Because programmer-controlled memory management is all tied up
> with the application program, it is very hard to tell exactly how
> much time is spent in it.  Thus, programmers don't know how much
> time their code spends in memory management.  I would be quite
> surprised if an optimizing compiler that understood memory management
> couldn't do better.

Ungar's paper in the Smalltalk implementation book measures where the
time goes.  In his case, it was constructing and destructing stack
frames!  (Ungar's generation scavaging algorithm is one of the reasons
garbage collection has such a good rep these days.  To use the language
from my earlier posting, he *did* a terrific job.)

I don't think optimizing compilers can understand memory management at
compile time.  It's hard enough to understand at run time!

> Ralph Johnson - University of Illinois at Urbana-Champaign

Paul S. R. Chisholm, AT&T Bell Laboratories
att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.