Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.object
Subject: Re: Garbage collection
Keywords: Garbage collection, object management
Message-ID: <52045@microsoft.UUCP>
Date: 5 Mar 90 20:08:15 GMT
References: <2616@ifi.uio.no> <51078@microsoft.UUCP> <25eb4850.41d0@polyslo.CalPoly.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 48

In article <25eb4850.41d0@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
>jimad@microsoft.UUCP (JAMES ADCOCK) writes:
>>In article <2616@ifi.uio.no> kai@ifi.uio.no (Kai Ivo Quale) writes:
>>>I'm looking for good books, articles, whatever, on garbage collection/
>>>object (de)allocation...
>>>Anyone out there have some tips ?
>>Be suspicious of what you read.
>Why?  Because the claims are too good to be true?

Well yes, actually.  If I were to write the generic GC paper it would go:

We tried Smith's GC written for the language Smirf on hardware Glop and
it was too slow for OurLang.  So we tried this new approach called OurWay 
running on OurGlop.  Initial tests using the representative target
application "LunerLander" were dissapointing, showing only a performance
improvement of 5%.  So we tuned OurWay a little bit.  And we re-wrote it
in OurGlop assembler using the hardware page faults supported on OurGlop
using a bunch of non-portable pointer hacks.  After a number of passes of
tuning OurWay, LunerLander now runs 400% faster than it did initially.
Furthermore, OurWay of GC'ing now only takes 20% of the total execution
time of the prototype OurLang interpreter [which is written in Algol.]

I claim the tuning of "OurWay", to optimize it to run on "OurGlop",
supporting "OurLang", used to write "LunerLander", with 10 Megabyte of RAM,
and 40 Megs of swap space, has little or nothing to do with the rest of
the world.

What is traditionally called "GC" encompases many related issues:

Do we attempt to discover objects that are no longer being used?
Do we attempt to re-use memory no longer used?
Do we attempt to avoid memory fragmentation?
Do we attempt to compact memory to get rid of fragmentation?
Do we attempt to make good use of virtual memory hardware?
Do we attempt to make good use of caches?
Do we attempt to be portable to various machines?
Do we have a linear memory or segmented one?
Do we have hardware support for virtual memory?
Do we use special pointer hacks?
Do we require special compiler/interpreter support?
Do we attempt to cluster objects?
Do we tune GC for a particular application? [maxamin]
Do we tune GC to try to match "all" applications? [minamax]
Do we support "real-time" --if so, how real?  one second response?
	one mSec response?

-- I have yet to see any GC scheme that I'd be willing to consider anything
close to general purpose.