
I agree that the internal GC approach could potentially have the same performance benefits as a traditional GC for the workload I described, especially with some cleverness in lock-free algorithms to handle multithreading. I assume it would probably perform quite a bit better actually, since it doesn't have to solve the finalization problem. As mentioned, so would a well written pool allocator - these are just two different approaches to amortizing memory allocation and deallocation costs. Of course, an internal GC or any pool allocator techniques I've heard of don't help with the huge developer and maintainer cost of correctly implementing pointer ownership rules for complex cyclical data structures without paying the CPU and memory cost of thread-safe cycle-safe reference counting. I spent far more time solving memory leaks, dangling pointers, and invalid memory dereferences than I did implementing, testing, and correcting actual geometry logic for my Delaunay triangulation package, and my only used resource was memory so I didn't need deterministic finalization. Increasing developer productivity when used for the right task is where a traditional GC really shines, I think. Gregory Peele, Jr. Applied Research Associates, Inc. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Achilleas Margaritis Sent: Tuesday, April 21, 2009 10:48 AM To: boost@lists.boost.org Subject: Re: [boost] request for interest in a garbage collection library
AFAICS, you can have an implementation of delete where "delete p" simply calls the destructor of the object pointed to by p and then passes p to an internal garbage collector that will reclaim the memory in due time. This way you have determinstic resource liberation *and* GC speed.
If you do that, what is the point of keeping the memory occupied by 'p' around? the object will be destroyed anyway and therefore it will not be of any use. By using pool allocators, allocation/deallocation can become as fast as when using a garbage collector. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost