Prev: C++ Memory Management Innovation: GC Allocator
Next: C++ Memory Management Innovation: GC Allocator
From: marlow.andrew on 21 Apr 2008 11:43
On 21 Apr, 19:13, xushiwei <xushiwe...(a)gmail.com> wrote:
> To obtain a copy of this paper in pdf format click here (http://
> xushiwei.com/local--files/gc-allocator/GCAllocator.pdf

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.

> When you creating a GC Allocator, You can use STD_NEW, STD_NEW_ARRAY
> to new objects.

> Frankly speaking, I don't like STD_NEW and STD_NEW_ARRAY.

Take a look at Pablo's article to see an alternative
approach that does not use macros or concepts.

One final point, it seems to me that there is a need
to bear thread safety in mind. You just say "it's not
needed". Can you explain why please?

Regards,

Andrew Marlow


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Lance Diduck on 21 Apr 2008 11:43
On Apr 21, 2:13 pm, xushiwei <xushiwe...(a)gmail.com> wrote:
> To obtain a copy of this paper in pdf format click here (http://
> xushiwei.com/local--files/gc-allocator/GCAllocator.pdf
> --
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++ needs more storage classes, much less
runtime storage classes.)
But nice work, and I will be sure to delve into this more
Thanks!


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: xushiwei on 21 Apr 2008 15:08
Another copy is also available on codeproject:
http://www.codeproject.com/KB/cpp/gc-allocator.aspx

On 4月22日, 上午2时13分, xushiwei <xushiwe...(a)gmail.com> wrote:
> 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.
>


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Chris Thomasson on 22 Apr 2008 02:13
<marlow.andrew(a)googlemail.com> wrote in message
news:a0074c8e-e576-4efb-bb9e-0cd97ae3fec6(a)a70g2000hsh.googlegroups.com...
> On 21 Apr, 19:13, xushiwei <xushiwe...(a)gmail.com> wrote:
>> To obtain a copy of this paper in pdf format click here (http://
>> xushiwei.com/local--files/gc-allocator/GCAllocator.pdf
>
[...]
> One final point, it seems to me that there is a need
> to bear thread safety in mind. You just say "it's not
> needed". Can you explain why please?

I just want to know if I can use this proposal to efficiently allocate in
one thread and free in another. As for the GC aspect, well, that's fine as
long as there are no mandatory requirements. I personally would think about
dropping C++ _if_ it "forced" me to use a GC. Even if the GC was
transparent, I need to be able to manually manage memory most of the time. I
don't want a GC running under my nose, so-to-speak... IMVHO, that would go
against the low-level nature of C++. I want to be able to use C++ to create
state-of-the-art allocators and garbage collectors... OS kernels, device
drivers and other low-level applications... Its the low-level nature of C++
that's particularly attractive... This is only my personal take on the
matter... Indeed.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: xushiwei on 22 Apr 2008 06:43
On 4��22��, ����9ʱ52��, "Chris Thomasson" <cris...(a)comcast.net> wrote:
> "Chris Thomasson" <cris...(a)comcast.net> wrote in message
>
> 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/6dc825ec99...
>
> basically, you create single-threaded allocator and plug it into the system,
> then, boom, its multi-threaded. If you have any questions, feel free to fire
> away...


I'm sorry but I think you misunderstand my points. I don't want to
create single-threaded allocator.

Why? Sharing GC Allocator in multi threads is not recommended. It
means that sharing memory between threads is also not recommended. If
you REALLY want to share memory, use new/delete or anything else.

For users of GC Allocator, we suggest that only use ONE BlockPool
instance in ONE thread, and ONE thread may use multiple PRIVATE
"ScopeAlloc" instances (depend on your requirement) to allocate
memory.

Lance Diduck is right:

Use non-static allocator instances to allocate memory instead of
global new/delete procedures. Then multithreads locks are OPTIONAL and
you can use explicit locks if you need.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 |  Next  |  Last
Pages: 1 2
Prev: C++ Memory Management Innovation: GC Allocator
Next: C++ Memory Management Innovation: GC Allocator