mct@pooh.Philips.Com (Mark C. Tucker) (02/18/89)
In article <DLD.89Feb13183030@F.GP.CS.CMU.EDU> dld@F.GP.CS.CMU.EDU (David Detlefs) writes: > >Boehm & Weiser: "Garbage Collection in an Uncooperative Environment" >Software Practice & Experience, September 88 > >Caplinger: "A Memory Allocator with Garbage Collection for C" >Winter 88 Usenix > I have been using Boehm's system, and feel that it provides usable garbage collection to C programmers. You don't have to worry about reference counting normally shared things like strings, tree nodes, .... That is, it will reclaim storage for things that are like heap allocated C-structs when they become unreachable. However, it will probably have a performance problem if you build a Lisp/Smalltalk-like application that uses a very long lived and huge `workspace'; Those applications require generation scavenging for performance, and probably depend on 'safety' features (bounds and pointer checking) not present in C or C++ to prevent programs from corrupting the (precious) workspace. But, as I said, Boehm's system free's you from everyday storage management considerations, and this I consider a great relief. I modified their system so that you can allocate `typed objects'. Typed objects supply a scan function (which knows exactly where to look for pointers inside instances) and, optionally, a delete-function (which is called just before sweep puts the instance on the free list.) Scan-functions enable heap resident structures to be scanned more quickly. Recall, Boehm' and Caplinger's techniques rely on very carefully inspecting every 32bit bitpattern (starting every 16bits on a Sun), to see if it might possibly be a pointer. The scan function for a type knows exactly which bits are pointers, and avoids this conservative scan through the bits of a value. The delete-function can be used to finalize objects. One use is for garbage collected files: when your FileObject is no longer accessible, its delete-function can close the file, then let sweep reclaim the storage for the FileObject. *** With regard to C++ delete~ members: My delete-function will not be called for instances allocated on the stack, and you are not guaranteed when the delete function will be called. C++ will call delete~ on locals before a function returns, and the programmer can depend on it (except, in the case of longjumps!!). But in my case, a spurious bit pattern might cause some object to be retained, and it might never be swept, so the programmer cannot count on the delete-function being called at any particular time. *** Plea from C++/front writers Here, I would put in a plea to C++ writers to build a table of [function_entry_point,entry_point_of_cleanup_code] pairs. Then, when we implement exceptions by a threaded stack of cleanup blocks, we can unwind the call stack, and invoke the cleanup routines for intervening stackframes. You can get Boehm's code from the Rice Archive server. I just sent a message to archive-server@titan.rice.edu with subject "send index" (no quotes), and the server will send you instructions on how to retrieve the files. The garbage collector is filed with SUN-specific code, even though it works for VAX and SPARC. Mark Tucker Philips Laboratories (914) 945-6361 345 Scarborough Road mct@philabs.philips.com Briarcliff Manor, NY 10510