[gclist] Finalizers & Reference counting.
Daniel C. Wang
Fri, 30 Aug 2002 00:47:54 -0400
At 09:15 PM 8/29/2002 -0700, Boehm, Hans wrote:
>My understanding is that the garbage collector in gcc replaces the prior use of obstacks, which are basically manually managed regions. I wasn't involved in the discussion, but the standard problems with this sort of approach are:
>1) It's easy to introduce dangling pointers. ANd the result is hard to debug.
>2) It's hard to bound the amount of garbage you retain in live regions.
>With automatic region inference (among other techniques), you can avoid (1), but I doubt that's practical here. I suspect you need GC within regions to really deal with (2).
You don't need region inference to avoid 1. You need region *checking*. However, a little local (intra-procedural) region inference is useful to avoid driving the programmer crazy.
The Cyclone design is the most practical region based system I've seen. (Of course their is only one other region based system around!)
Region-based Memory Management in Cyclone, Dan Grossman, Greg Morrisett, Trevor Jim, Michael Hicks, Yanling Wang, and James Cheney. ACM Conference on Programming Language Design and Implementation, Berlin, Germany, June, 2002.
As for 2. This indeed does seem to be the case in practice. Of course with a little work you can implement a GC with regions. A copying GC really is just moving objects from the "from region" to the "to region". So in a theoretical senses you just need regions. You just build you GC on top of them.
This of course lets me insert a shameless plug for my dissertation
Managing Memory with Types (Thesis)
which I probably should have announced a while back. It extends some of the original work I did previously and fleshes out enough details so you can build a type-safe garbage collected system for non-toy languages.
It discusses how to do "stack scanning" in a type safe way, and provides some interesting ideas that should let you encode stack allocation by adding linear typing to the mix.