Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Message-ID: <hbakerCzIs4H.Fup@netcom.com>
Keywords: storage garbage collection incremental search method
Organization: nil
References: <3ai2ol$3ua@gate.fzi.de> <CzHCvp.9rM@rheged.dircon.co.uk>
Date: Sat, 19 Nov 1994 14:55:29 GMT
Lines: 60

In article <CzHCvp.9rM@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:
>In article <3ai2ol$3ua@gate.fzi.de>, Ulrike Koelsch <koelsch@fzi.de> wrote:
>>I am searching for a method of incremental garbage collection working on the 
>>storage of an object-oriented database system.
>>
>>How can I avoid getting inconsistencies by applications setting and deleting 
>>references on a part of the memory my garbage collector examines in
>>some interrupted runs.
>
>I've always believed that a reference counting garbage collector had a
>lot going for it, particularly in systems which require continuous
>performance. This application seems to me a case in point.

>I have played with the design of a system which held a
>series of pages each of which was organised as an array of cells.
>Objects which would not fit in a single cell were held separately in a
>heap (HSOs or Heap Space Objects), but each was referenced through a
>single, single celled object (an HSR). The HSR held the reference
>counter for the HSO. Cells on each page were allocated from and
>returned to a free list, and the page held a count of the number of
>allocated cells.
>
>A central lookup table indirected references to the pages, so that a
>pointer would be <page no><offset>, and also held centrally was a
>pointer to the 'current page'. New cells would always and only be
>allocated from the current page. When the 'current page' became full,
>the least full other page would become the new 'current page'. If all
>existing pages were full, a new page would be requested from the
>heap (if a page ever became empty it would of course be returned to
>the heap).

There's nothing particularly wrong with this approach; in fact, it
looks a good deal like some of the earlier Smalltalk systems.
(Smalltalk likes to have an indirect scheme, because the 'become'
operation of Smalltalk allows an object to become something totally
different, which may require lots more space.  Many Lisps use indirect
schemes for variable-sized objects -- e.g., vectors, strings, etc.)

You should be aware that reference decrements can 'cascade' if a large
complex object is freed as a whole.  Unless some care is taken to
decrement counts 'lazily', you may experience hiccups when this
happens.  Lazy count decrementing has been discussed on the net, and
is briefly covered in my 'List Processing in Real Time' paper
(available in my ftp directory).

My experience has shown that reference counting can reduce total
address space consumption, but at the cost of increased processing
cycles (relative to tracing/copying GC).  With cheap memory and
expensive CPU cycles, most people have opted for tracing/copying GC as
a better tradeoff.  But each system is different, and I don't think
that there is a 'slam dunk' argument for any of these systems, at
least so long as you don't have directed cycles of garbage.

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
      Contact hoodr@netcom.com if you have trouble ftping




