Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: Gregory Peele ARA/CFD (gpeele_at_[hidden])
Date: 2009-04-21 11:03:30

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_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Achilleas Margaritis
Sent: Tuesday, April 21, 2009 10:48 AM
To: boost_at_[hidden]
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