GC alternatives?

[Nathan Hawkins]

On Mon, 15 Apr 1996, Francois-Rene Rideau wrote:

> > I was thinking about ways to do GC, when it occurred to me:
> > why not do something that explicitly declares object dependacies, instead
> > of polling for them. Something that works analogously (something like
> > that) to the "make" utility, but with memory blocks instead of files.
>    As Eric pointed out, the role of the GC is precisely to track down
> those dependencies.
>    You're right to wonder whether it might not be particularly
> helpful to accept some kind of explicit list of mutual dependencies,
> by maintaining a list of pointers to self.
> Such system seems far too expensive for usage by in-memory objects,
> and it does not resolve the need for a GC if circular objects are allowed.
> However, it is exactly what might be done
> for some kinds of worldwide distributed objects,
> whose migrations or modifications should be reported to dependent objects.

It wasn't a great idea, but you're right, it might be good for 
distributed objects. GC over a network might be way too much overhead...

> >[using mostly stacks & alloca, when heap is not compulsory]
>    Stack allocation sure is more efficient than GC, *when it is possible*,
> but it causes problems when using persistent continuations,
> that the HLL should support.
> Continuations are usually implemented by copying the whole stack
> (which also means no absolute pointers to the stack at safe points).
>    My guess is that time-critical/real-time stuff
> would be optimized and use separate stacks anyway,
> so the common code could use the SML-like
> heap-based continuation passing style without problem
> (or perhaps the CAML-like stack copying ?
> but I guess the HLL style I think about would prefer the SML approach).

Pointers to the stack could always be relative. No big problem there. I 
have no idea what you're talking about otherwise. (More reading I don't 
have time for... 8-)

> > This is a relatively simple and fast way to do things, but could the HLL
> > cope with it? If not, is there some other alternative that would work
> > better, or is GC really the only way to go?
>    GC is just *needed* because of persistency:
> if we allowed the least memory leak, or didn't compact memory,
> the system would crash unrecoverably after some time.
>   Now, if we can arrange so fast minor GCs suffice until
> there's a moment when no one uses the machine
> and we can try a slow major GC, that's fine.
> However, this is the kind of refinement that's very useful,
> but not essential for a first implementation.

Well, I was just trying to explore the topic a little bit. You're right 
about persistant memory.

As for useful refinements: it is nice to plan for this sort of thing, 
since a little thinking ahead can help avoid future headaches.

*utsl*