Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.lang.c
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!freenet.columbus.oh.us!pacific.mps.ohio-state.edu!math.ohio-state.edu!usc!hookup!news.mathworks.com!gatech!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality.
Message-ID: <hbaker-0708952138580001@192.0.2.1>
Sender: hbaker@netcom20.netcom.com
Organization: nil organization
References: <3vnvr1$9lb@jive.cs.utexas.edu> <9507261647.AA14556@aruba.apple.com> <3vb382$dtr@jive.cs.utexas.edu> <hbaker-3107951007190001@192.0.2.1> <3vnghm$sdl@info.epfl.ch> <3vtvi5$g8a@kernighan.cs.umass.edu> <kelvin.807660304@kickapoo>
Date: Tue, 8 Aug 1995 05:38:58 GMT
Lines: 66
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5010 comp.lang.misc:22547 comp.lang.lisp:18596 comp.lang.c:150501

In article <kelvin.807660304@kickapoo>, kelvin@cs.iastate.edu (Kelvin
Nilsen) wrote:

> pop@cs.umass.edu ( Robin Popplestone ) writes:
> 
> >> In article <3vnghm$sdl@info.epfl.ch>,
> >> Stefan Monnier <stefan.monnier@epfl.ch> wrote:
> >>In article <hbaker-3107951007190001@192.0.2.1>,
> >>Henry Baker <hbaker@netcom.com> wrote:
> >>] IMHO the major gain from compaction is to defragment the address space,
> >>] but as Paul's recent work has shown, one may not have to do this very
> >>] often.
> 
> >And Paul Wilson writes in <3vnvr1$9lb@jive.cs.utexas.edu>
> 
> >> Right. For "most" programs (that have been studied in enough detail, that
> >> is), it looks like you never have to do it at all.  Nobody's studied
> >> really long-running programs, though, and it's not clear whether
> >> fragmentation will accumulate over time, or stabilize at an acceptable
> >> level.

I agree with Kelvin about not giving up on compaction completely, and disagree
with Paul that you _never_ have to do it.

While a significant fraction of the best brains in the computer business over
the past 30 years have been aimed at optimizing architectures so that objects
don't have to move (and thereby inadvertently penalizing any programs that
actually _do_ move objects), they haven't completely succeeded at beating
Robson and/or the second law of thermodynamics (in the sense I used it
in my Sigplan Notices paper).  Therefore, up until the point at which
your address space is so incredibly trashed that you can't allocate anything
of any reasonably size any more, your program will actually run pretty
well, because the memory hierarchy stuff (VM, cache) are doing all of the
dynamic moving of data for you, without your conscious control, and indeed
without much ability on your part to affect it much even if you wanted to.

The problem, like that of many GC systems, is that 'reorganizing' address
space is a relatively massive and expensive undertaking, and will not
happen very fast.  Furthermore, it is the kind of process that memory
hierarchies hate because their locality assumptions fail completely in
the face of such reorganization.

Therefore, unless one can somehow organize this process so that it takes
a relatively small percentage of the system, and doesn't interfere too
much with the normal operation of the program, the cure of reorganization
may be worse than the disease of fragmentation.

However, neither the disease nor the cure need be fatal, but they do have
to be approached with a great deal of subtlety.

If you have enough memory, you can either incrementally copy the stuff
to another processor, and let it do the reorganization for you (easier
in this case than in the reachability GC case), or have the same processor
do a kind of background reorganization task.  It is important, IMHO, that
the background task _know_ it is a background task, and be able to inform
the memory hierarchy of its second-class status, so that its activities
will not hurt the more important activities of the application program.

Incremental copying GC's try to do these things in this way (within the
constraints of the HW & OS).  The only slight variation is that with the
way the current generation of HW architectures are optimized, it may not
be optimum to copy _all_ the time, but only once in a while.

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