Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!news.mathworks.com!tank.news.pipex.net!pipex!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!hpscit.sc.hp.com!hpax!wang
From: wang@cup.hp.com (Thomas Wang)
Subject: Re: allocator and GC locality.
Sender: news@hpax (News Admin)
Message-ID: <DD0722.Hst@cup.hp.com>
Date: Tue, 8 Aug 1995 17:54:02 GMT
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> <hbaker-0708952138580001@192.0.2.1>
Nntp-Posting-Host: capella.cup.hp.com
Organization: Hewlett-Packard
X-Newsreader: TIN [version 1.2 PL0.7]
Followup-To: comp.lang.dylan,comp.lang.misc,comp.lang.lisp
Lines: 34
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5017 comp.lang.misc:22562 comp.lang.lisp:18611

Henry Baker (hbaker@netcom.com) wrote:

> 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.

Precisely.  No relocation/compaction is likely to have the best performance
for this reason.  Pathological fragmentation is still a problem, which need
to be addressed.  Interestingly enough, present day VM hardware is already
sufficient to minimize the fragmentation problem through NOT MAPPING the
free fragments.  So the true problem lies in OS software, which provides no
API to portably access this feature.  What needs to be done is for the
researchers to present a standard package of API to various OS standard bodies
to make sure wide adoption of various VM access functions.

In one sample implementation, I imagine a non-moving incremental garbage
collector with a software write barrier.  This collector uses a binary buddy
system memory allocator, which minimizes external fragmentation.  Internal
fragmentation is minimized through VM hardware of not mapping the free
fragments.  Sub-page fragmentation is minimized by grouping small objects
into pools.  This collector would have good interactive performance, and
should be cache friendly as well.

Regards.

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

  -Thomas Wang              (Software Engineer, Enterprise Objects Program)
   wang@cup.hp.com          http://hpeopose.cup.hp.com/~wang/wang.html

