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

Subject: Re: [boost] request for interest in a garbage collection library
From: Edouard A. (edouard_at_[hidden])
Date: 2009-04-21 11:10:34

On Tue, 21 Apr 2009 16:57:33 +0200, joaquin_at_[hidden] wrote:

> The point is that deferring memory release to the next GC round can be 
> faster than
> releasing every little piece of memory immediately, at least in some 
> scenarios:
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details
> 
> Take into acount that free(x) is by no means free in terms of execution 
> time (no pun intended)
> --some bookkeeping has to be done by the internal memory manager when 
> freeing a
> block of memory.

A decent memory allocator avoids actually freeing memory when you call
free/delete. Instead, the block will be marked as available and future
memory allocation may use this block (if it fits). This operation is
inexpensive. Depending on your memory constraints, actual deallocation may
even never happen (see STLPort default allocator).

Memory pool can go further and be even more efficient because all blocks
have the same size, making reusing very easy and efficient.

Garbage collector just displace the memory management problem. Large
applications still need careful design. No silver bullet. I'm very doubtful
about the benefits of a C++ garbage collector but I'd be very happy to be
proven wrong.

-- 
EA