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). Another copy is
also available on google docs (http://docs.google.com/View?
docid=dds5zgx6_353dc5k4fcq) in html format.

Introduction

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

What is GC Allocator?

"xushiwei" gmail.com> wrote in message
news:d21bda62-0079-4023-99ef-cc90c66b5831@q1g2000prf.googlegroups.com...

[...]

AFAICT, your implementation is not thread-safe. For instance, I could not
use it to implement a producer/consumer pattern. Thread A allocates blocks
and passes them to thread B which frees them. Am I missing something?

"xushiwei" gmail.com> wrote in message
news:d21bda62-0079-4023-99ef-cc90c66b5831@q1g2000prf.googlegroups.com...

[...]

xushiwei ha scritto:

As you did not mention it, I believe you are unaware that a garbage
collector proposal for C++ has already been proposed and that it is
"actively pursued" by the committee. You may read it here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2310.pdf

Unfortunately, the committee also decided that it was more important to
get the new standard approved by the end of this year and the GC
proposal was not ready to meet such deadline. Therefore only minimal GC
features are likely to be present in C++0X (see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2527.html)
while the rest of the GC proposal has no set schedule.

HTH,

Ganesh

On 21 Apr, 19:13, xushiwei gmail.com> wrote:

I took a quick look with particular interest
in what you have to say about scoped allocators.
It seems to me that there is some overlap with
what you are doing and the work by Pablo Halpern in
his N2523 submission to WG21 entitled "The Scoped Allocator
Model". See
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2523.pdf

IMO Pablo's proposal is more thought through.
I recommend you take a look.

[ huge prose snipped ]
The prose snipped seems to be a copy of the PDF article.
I am suprised the moderator did not comment on this.
It makes your post very long.

On Apr 21, 2:13 pm, xushiwei gmail.com> wrote:

Very Nice presentation!!
There aren't any real earth shaking new ideas here, but a good
overview of why choosing the best allocator for the job makes a huge
difference.
I have long been a fan of non-static allocator instances, and they do
make a huge difference esp in MT programs. There has been some recent
work with stateful allocators in the standard, but most of this work
was geared to changing the semantics of "regular type" rather than
improving allocator support in the library. (the idea is that each
allocator instance is just like another storage class. It kinda makes
sense, until you wonder why C...

Another copy is also available on codeproject:
http://www.codeproject.com/KB/cpp/gc-allocator.aspx

On 4

"Chris Thomasson" comcast.net> wrote in message
news:c4Odnch9beA_QJHVnZ2dnUVZ_viunZ2d@comcast.com...

If I am correct, well, "perhaps" I have something that just might be able to
help your allocator. There is an invention that can transform most
single-threaded memory allocators into scaleable multi-threaded ones; here
is my initial post:

http://groups.google.com/group/comp.arch/browse_frm/thread/6dc825ec9999d3a8

On Apr 21, 10:43 pm, marlow.and...@googlemail.com wrote:

Pablo doesnt actually propose any allocator. It only mentions a
technique for applying allocators to containers. The only "scoped
allocator" in there is a wrapper around the system allocator.
Pablos work's doesnt mention anything on how to write allocators that
could be scoped. Rather, that if they could be written then this is
how to pass them from one container to another.
And that is the rub-- writing an allocator that could be "scoped" is
very hard indeed. The stated intent of "scoped allocators" is to
change the semantics of STL "regular type" such that any property that ...

On 4月22日, 上午10时43分, marlow.and...@googlemail.com wrote:

Before I post this article, I read submissions to WG21 related to
Allocator, such as n1850, n1509, n2387, n2523(n2446), n2436, n2486,
n2524, n2554.

You mentioned "The Scoped Allocator Model", so I read it though again
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2523.pdf and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2446.pdf). I
don't find common points between them except the similar name:-) Would
you point out them for me?