GC alternatives?

[Francois-Rene Rideau]

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


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


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


-- Fare'