Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.lang.c++
Subject: Re: garbage collection
Keywords: compaction
Message-ID: <44731@oliveb.olivetti.com>
Date: 13 Jul 89 19:48:09 GMT
References: <404@osc.COM>
Sender: news@oliveb.olivetti.com
Reply-To: chase@Ozona.UUCP (David Chase)
Organization: Olivetti Research Center, Menlo Park, CA
Lines: 38

In article <404@osc.COM> tma@osc.COM (Tim Atkins) writes:
>
>
>I am working on an application that needs to move objects between different
>heaps.  The problem I'm attempting to get a handle on is how to avoid a
>stack update of what looks like a pointer to one of the objects moved but is
>actually some long or other piece of data that happens to contain the same
>values.

Joel Bartlett at DEC WRL(? if not WRL, then SRC) (both in Palo Alto)
did something with compacting collectors that may help you with this.
I believe that there's a technical report describing this.  The
insight is that a "new" page need not really be "new"; it can be an
old page that you decide to call "new".  Given that, you can either
(a) copy everything out of an old page and recycle it or (b) elect not
to copy something out, because it is pointed to by something in the
stack which you are not allowed to change because it might be an
integer (an "ambiguous root").  That is, Bartlett's scheme "cheats"
and avoids your problem.  (There's obviously more details to this -- get
the tech report or paper if you are interested.)

Plan B (not well thought out, by the way) would be to generate a special
piece of code for each procedure in your application that would manage
its frame.  All this gets put in a table somewhere, and the collector
unwinds the stack, invoking the appropriate piece of code for each
activation record.  Getting this to work correctly is probably not what
most people call "fun", but it's an idea.  (Exception dispatchers based
on similar technology have worked very well.  Non-standard or especially
intricate calling conventions make it very hard.)

I'm not sure, but Robert Shaw (at HP Labs) may be working on a compacting
collector that gets along with C.

Whatever you do, be sure to watch out for "interior pointers"; i.e., a
pointer to a field within a heap-allocated struct.
            (                                    )

David