GC alternatives?

Nathan Hawkins utsl@one.net
Sat, 13 Apr 1996 10:02:06 -0400 (EDT)


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.

Also, what about using a split heap, with one being contained within the 
r-stack (something similar to alloca), and the other being a more 
conventional heap. This would allow objects to be automatically 
deallocated when the context they were allocated within exits, while 
allowing long term allocations to be handled explicitly.

This would doubtless be more efficient than GC, but would it work for the 
HLL?  According to a paper on real-time GC (in an archive of papers I 
found on the web, pointed to by the Tunes page, but I forget where), I 
read that stack-allocation is actually better than GC for short-term 
objects, and that these make up the majority of allocations in a HLL.

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?

*utsl*