I'm trying to write a small self-educational lisp, and I've run into
problems with garbage collection.
1) First, garbage collection seems like a black box. I haven't seen
any lisps where you can control the behavior of the garbage collector.
Specifically, it would be nice if small short lived objects could
be identified by the compiler and pushed onto the stack, small longer-lived
objects could be put in a separate heap that gets cleaned alot(parhaps
stop-and-copy gc, or generational), and the large date objects could be
put in a more conservative heap, perhaps using reference counting.
Is having this sort of thing open to the user's control (several
primitive-alloc functions?), or is it too machine dependent to be useable?
2) The other problem I had was threads. Is it possible to efficiently
implement 'user level' garbage collection in a multithreaded lisp, or
does GC have to be part of the 'kernal'?
3) Has any work been done on optimizing compilers that push predetermined
sort-lived objects onto the stack instead of allocating them on the heap?
Thanks for any possible help.
mike
In article <··········@magus.cs.utah.edu> ········@kira.cs.utah.edu (Michael Callahan) writes:
>I'm trying to write a small self-educational lisp, and I've run into
>problems with garbage collection.
>
>1) First, garbage collection seems like a black box. I haven't seen
>any lisps where you can control the behavior of the garbage collector.
>Specifically, it would be nice if small short lived objects could
>be identified by the compiler and pushed onto the stack, small longer-lived
>objects could be put in a separate heap that gets cleaned alot(parhaps
>stop-and-copy gc, or generational), and the large date objects could be
>put in a more conservative heap, perhaps using reference counting.
>
>Is having this sort of thing open to the user's control (several
>primitive-alloc functions?), or is it too machine dependent to be useable?
>
>2) The other problem I had was threads. Is it possible to efficiently
>implement 'user level' garbage collection in a multithreaded lisp, or
>does GC have to be part of the 'kernal'?
>
>3) Has any work been done on optimizing compilers that push predetermined
>sort-lived objects onto the stack instead of allocating them on the heap?
This sounds like a pretty good PhD thesis proposal to me....
Seriously, there's lots of papers that discuss various portions of what
you ask. There are compiler optimizations that discover which objects
can be stack allocated, there are generational algorithms that utilize
lifetimes, there are GC's that combine reference counting, there are GC's
that provide for various hooks, there are GC's that allow for multiple
threads, there are GC's that are part of kernels, etc., etc.
Unfortunately, when you currently put all this stuff together, you get
something that is complex and difficult to understand and optimize.
After you have studied the literature, there are many, many interesting
problems that you have identified to work on.
In article <··········@magus.cs.utah.edu> ········@kira.cs.utah.edu (Michael Callahan) writes:
1) First, garbage collection seems like a black box. I haven't seen
any lisps where you can control the behavior of the garbage collector.
Is having this sort of thing open to the user's control (several
primitive-alloc functions?), or is it too machine dependent to be useable?
There was a paper accepted to ECOOP94, by Giuseppe Attardi and Tito
Flagella on an open implementation of a garbage collector. This is
part of the rapidly growing trend of opening up all kinds of substrate
software to user intervention, rather than trying to make perfect
black boxes. I imagine you can get a copy of this paper by sending
mail to Beppe, the address is ·······@di.unipi.it.
Gregor