{ Please note that top-posting is discouraged in this group. -mod }
These days I spent a lot of time researching Boehm GC, Hoard/
HeapLayers/reaps, streamflow, dlmalloc, etc.
Yes, "GC Allocator" is a region allocator. It's no innovation. But:
This (ScopeAlloc) is not a normal region allocator. All ScopeAlloc
instances in the same thread share their freelist. This makes you can
define a lot of ScopeAlloc instances (depends your needs). You even
can define a ScopeAlloc instance for each allocation.
Most allocators optimize allocating a lot of objects. If ONE allocator
instance only allocates ONE object instance, they become slower than a
normal new/delete allocation.
Since you can define a lot of ScopeAlloc instances as you need, So It
doesn't waste too much memory as normal region allocators.
ScopeAlloc is useful. For example:
* When you are writing an io component (eg. a word file writer:
http://xu****wei.com/the-fastest-word-file-writer).
* When you are writing a search engine.
* When you are writing a layout render engine.
* When you are responding a http request.
And I don't think it is all of C++ memory management. if you implement
algorithms that are related to t (that is, how many time of the
algorithm spent is unsure.), ScopeAlloc doesn't fit you directly.
Last, I think that we need a standard region allocator. Yes, maybe it
is have limits. But just like unique_ptr (auto_ptr), scoped_ptr, they
are useful but not a general solution.
On 4月29日, 上午5时58分, Yongwei Wu <wuyong...@[EMAIL PROTECTED]
> wrote:
> On Apr 23, 5:22 am, xu****wei <xu****we...@[EMAIL PROTECTED]
> wrote:
>
> > In fact, "GC Allocator" is NOT "GC".
>
> > "GC Allocator" focus:
>
> > 1. It is a better "Smart Pointer".
> > 2. Deleting objects manually is no need if you use "GC Allocator".
>
> I found it difficult to justify your statement. How do you deallocate
> objects, really? You did not explain well in the PDF, and a glance at
> the code indicated that you simply do *not* deallocate objects in the
> middle of a function. If I did not read wrong, your work is not
> suitable in most real-world cases that require a program to run for
> more than a short while.
>
> > 3. 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.
>
> > You can consider "GC Allocator" as a "Smart Pointer" or a "Allocator",
> > but It isn't a "GC".
>
> I do not think your allocators are GC at all. And it should not
> called in the current name.
>
> Best regards,
>
> Yongwei
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
