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*