Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk