Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ucselx.sdsu.edu!petunia!polyslo!ttwang
From: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Newsgroups: comp.object
Subject: Re: Garbage collection
Keywords: Garbage collection, object management
Message-ID: <25f324e9.1488@polyslo.CalPoly.EDU>
Date: 6 Mar 90 02:48:09 GMT
References: <52045@microsoft.UUCP>
Reply-To: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Distribution: usa
Organization: Cal Poly State University -- San Luis Obispo
Lines: 59


jimad@microsoft.UUCP (Jim ADCOCK) writes:

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

>Do we attempt to discover objects that are no longer being used?
Yes.
>Do we attempt to re-use memory no longer used?
Yes.
>Do we attempt to avoid memory fragmentation?
Periodically fix memory fragmentation.
>Do we attempt to compact memory to get rid of fragmentation?
Yes, see above.
>Do we attempt to make good use of virtual memory hardware?
Not necessary.
>Do we attempt to make good use of caches?
No.
>Do we attempt to be portable to various machines?
Yes.  Less than 3 pages of non-portable code should be good enough.
>Do we have a linear memory or segmented one?
The programmer don't care.  Only the GC implementor need to know the memory
model.
>Do we have hardware support for virtual memory?
Not necessary.
>Do we use special pointer hacks?
No pointer hacks!  This sort of trick is not needed if the language don't
use physical pointers.
>Do we require special compiler/interpreter support?
No.  The GC can be written as an object code library.
>Do we attempt to cluster objects?
Yes.  I am certain that object clustering is a big win.
>Do we tune GC for a particular application? [maxamin]
Tuning by using GC initialization parameters.
>Do we tune GC to try to match "all" applications? [minamax]
No.
>Do we support "real-time" --if so, how real?  one second response?
>	one mSec response?
Yes.  Two flavors.  One with 1/2 second response, the second one with
milli-second response time.

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

The one thing that will kill GC performance is the use of physical pointers.
C is a perfect example of this.  If the language would access things through
handles, then a portable GC can be written with good enough performance for
it to be useful.

This has been true for Smalltalk systems for about 4 years now.

"Physical pointers considered harmful."



 -Thomas Wang ("This is a fantastic comedy that Ataru and his wife Lum, an
                invader from space, cause excitement involving their neighbors."
                  - from a badly translated Urusei Yatsura poster)

                                                     ttwang@polyslo.calpoly.edu