Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news4.ner.bbnplanet.net!news3.near.net!noc.near.net!news.mathworks.com!gatech!news.uoregon.edu!news.bc.net!info.ucla.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Message-ID: <hbaker-3107951026250001@192.0.2.1>
Sender: hbaker@netcom15.netcom.com
Organization: nil
References: <9507261647.AA14556@aruba.apple.com> <3v8g7l$cge@jive.cs.utexas.edu> <3vac07$ptf@info.epfl.ch> <3vb382$dtr@jive.cs.utexas.edu> <3vbl70$bht@fido.asd.sgi.com>
Date: Mon, 31 Jul 1995 18:26:25 GMT
Lines: 77
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:4930 comp.lang.misc:22407 comp.lang.lisp:18492 comp.object:36074 comp.arch:59996

In article <3vbl70$bht@fido.asd.sgi.com>, mikemac@engr.sgi.com (Mike
McDonald) wrote:

>   I should preface my comments with a statement stating I know next to
> nothing
> about modern allocators and GCs. The last time I studied any GC in
> detail was for
> a graduate compiler construction class at UIUC in 83/84. After I
> presented my
> report on Henry Baker's generational (I think) GC, the professor stated
> that GC
> had nothing to do with compilers. I wimped out and let it slide instead
> of
> challenging him.

If you are referring to my April 1978 CACM paper, it does _not_ describe
what people would now call a 'generational' GC, but a straight-forward copying
GC which is scheduled in peculiar way.

[There seems to be a lot of confusion about this.  Coplien's "Advanced
C++ Programming Styles and Idioms", Addison-Wesley, 1992, is also very
confused about this.  He describes my 1978 GC as a "mark-sweep" gc, which
characterization most GC people would disagree with.]

If anyone is interested, this paper is available online at

ftp://ftp.netcom.com/pub/hb/hbaker/RealTimeGC.html (also .ps.Z).

>   I too am in favor of GCs from a sofware engineering point of view.
> I've spent
> too much of my life already worrying about malloc/free in both my
> programs and in
> others.

What, you don't work for 'Purify'??  ;-)

According to Jon Bentley and Bjarne Stroustrup, rewriting malloc/free
is one of the most rewarding forms of entertainment for SW people.  ;-)

>   I don't think allocation order and size gets you vary far. First,
> allocation
> order tells you nothing about usage order. The order of allocation is
> very
> dependant on the algoritms used and the style of the writer. Changing
> the order
> of a couple of C lines can drasticly change the order of allocation.

Exactly!!  Which is why many 'studies' aren't worth the paper they are
printed on.

-----

My own pet peeve is _weak_ language type systems like Ada and C++ that
_force_ you to break apart a single object into a number of smaller subobjects
_that are separately mallocated_ even when you know how to manage the
object as one object in assembly language.  Stroustrup's C++ is especially
'pointer-happy', as a perusal of the following two books will show:

Stroustrup, Bjarne.  "The C++ Programming Language, Second Edition".  Addison
Wesley, 1991.

Ellis, M.A. and Stroustrup, B.  "The Annotated C++ Reference Manual".
Addison Wesley, 1990.

Whenever things get tough, C++ wimps out and forces another pointer indirection.

Of course, this 'solves' the problem for the C++ implementor, but throws
a much larger problem over the fence onto the poor application writer
and/or memory manager, who is now forced to deal with a much higher load
of smaller objects.

Whoever said that C++ doesn't force you to pay for features you don't use
hasn't ever programmed in C++ to any extent.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
