Re: [boost] C++ Memory Management Innovation: GC Allocator

From: Lance.Diduck_at_[hidden]
Date: 2008-04-22 15:26:51

 Steven Watanabe wrote:
>As I understand it, if I have a List that exists for the duration of
the program, and I am often 
> adding and removing elements, then the memory for the elements will
just build up until the List is destroyed.
In fact, with some implementations of std::list will support this
behavior with a suitable allocator. See pg 31 of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2486.pdf for an
example. So the idea has been around for some time -- an allocator could
allocate live objects and not just raw memory. 

One thing that has always struck me, was that C++ from day one had the
ability to override allocators everywhere in all sort of interesting
ways, but there remains to this day no real understanding of just what
you can do with them. Techniques like shiwei xu illustrated should be
commonplace. However, just about all attempts at allocator writing are
"malloc replacements." In other words, if it isn't a drop in replacement
for malloc, the preception is that it just isn't a serious allocator.
The fact is that the vast majority of C++ use cases do not require
contiguous memory allocations of arbitrary sizes determined at runtime,
which drastically simplies allocator writing. This enable smart
programmers to make phenomenal performance gains, and keeps C++ in
business.

Given that the lockfree library I am interesting in collaborating on
heavily relies on specialty allocators, I would also be interested in
collborating on a expanded boost allocator library.

Lance

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Steven Watanabe
Sent: Tuesday, April 22, 2008 2:45 PM
To: boost_at_[hidden]
Subject: Re: [boost] C++ Memory Management Innovation: GC Allocator

AMDG

shiwei xu wrote:
> Most of the C++ programmers do not benefit from "Garbage Collection"
> technique (GC). They are sick of deleting objects but have to do this.
> There are some C/C++ memory GC implementations, but they are complex 
> and are not widely used.
>
> I am going to introduce a new memory management technique named "GC 
> Allocator". "GC Allocator" isn't an implementation, but a concept.
> Now, we have two "GC Allocator" implementations, named "AutoFreeAlloc"
> and "ScopeAlloc".
>
> This article consists of three parts:
>
>    1. What is GC Allocator?
>    2. GC Allocator implementations: ScopeAlloc and AutoFreeAlloc
>    3. Applications based on GC Allocator For more information, see 
> http://www.codeproject.com/KB/cpp/gc-allocator.aspx
>
> To obtain a copy of this paper in pdf format click 
> here<http://xushiwei.com/local--files/gc-allocator/GCAllocator.pdf>(or
> from google
> code <http://code.google.com/p/stdext/downloads/list>).

If I understand correctly, your GC allocators delete all allocated
blocks when the allocator itself is destroyed, or can be explicitly
forced to free everything.  Basically, this works by imposing a hard
upper bound on the lifetime of a group of objects, rather than dealing
with them separately.
I think that this is useful in some contexts.  (Enough that I
implemented a simple version about a year ago).  However, it is not
always applicable.  Consider your List template.  As I understand it, if
I have a List that exists for the duration of the program, and I am
often adding and removing elements, then the memory for the elements
will just build up until the List is destroyed.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.
        
E-mails are not encrypted and cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses.  The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission.  
If verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or related financial instruments.