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

Subject: Re: [boost] request for interest in a garbage collection library
From: joaquin_at_[hidden]
Date: 2009-04-22 02:36:45

Gregory Peele ARA/CFD escribió:
> 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.
>   

Hi Gregory,

I agree with you that alledged benefits of GCs have to be sought in the 
realm of
increased productivity --not that I like GCs, but that's another matter. 
I just wanted
to point out that performance cannot possibly be presented as an 
advantage of
garbage collection vs. RAII.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo