http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=79746
Quoted from Andrei:
> This entire discussion gets me thinking - could an alternate stack be a
> good (or even better) solution? Consider a global per-thread
> "superstack" - a growable region that allocates memory in large chunks
> and makes sub-chunks accessible in a strictly LIFO manner. The
> primitives of the superstack are as follows:
> void* SuperStack.allocate(size_t bytes);
> void SuperStack.free(size_t bytes);
> size_t SuperStack.slack();
> The SuperStack's management is a singly-linked list of large blocks. The
> slack function returns how many bytes are left over in the current
> chunk. If you request more than slack bytes, a new chunk is allocated
> etc. A SuperStack can grow indefinitely (and is susceptible to leaks).
> Some convenience functions complete the picture:
> T[] SuperStack.array(T)(size_t objects);
> enum Uninitialized { yeahIKnow }
> T[] SuperStack.array(T)(size_t objects, Uninitialized);
> Freeing chunks should not be done immediately in order to avoid
> pathological behavior when a function repeatedly allocates and frees a
> chunk just to fulfill some small data needs.
> With the SuperStack in place, code could look like this:
> void foo(in size_t s)
> {
> auto a = SuperStack.array(int)(s, Uninitialized.yeahIKnow);
> scope(exit) SuperStack.free(s);
> ... play with a ...
> }
> Is there interest for such a thing?
> Andrei
Comment #1 by alex — 2012-10-09T18:42:22Z
Let's open an issue if there is actual interest or someone provides a patch.
Comment #2 by chadjoan — 2012-10-09T19:08:23Z
(In reply to comment #1)
> Let's open an issue if there is actual interest or someone provides a patch.
I still want this. I don't know how to implement it efficiently and I haven't used it because it doesn't exist :/
Comment #3 by alex — 2012-10-09T19:19:20Z
Well, at some point, we have to close enhancement requests because nobody's worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be done, but just a reflection of the fact that any core developers are unlikely to work on this (at least right now).
By all means, reopen if someone starts work on this. :)
(Besides, this should probably be filed against Phobos, not DRuntime.)
Comment #4 by chadjoan — 2012-10-09T19:21:01Z
(In reply to comment #3)
> Well, at some point, we have to close enhancement requests because nobody's
> worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be
> done, but just a reflection of the fact that any core developers are unlikely
> to work on this (at least right now).
>
> By all means, reopen if someone starts work on this. :)
>
> (Besides, this should probably be filed against Phobos, not DRuntime.)
Makes sense. Thank you.
Comment #5 by dmitry.olsh — 2012-10-10T00:31:39Z
(In reply to comment #4)
> (In reply to comment #3)
> > Well, at some point, we have to close enhancement requests because nobody's
> > worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be
> > done, but just a reflection of the fact that any core developers are unlikely
> > to work on this (at least right now).
> >
> > By all means, reopen if someone starts work on this. :)
> >
> > (Besides, this should probably be filed against Phobos, not DRuntime.)
>
> Makes sense. Thank you.
It's here. Name's RegionAllocator.
Was proposed for allocator proposal about a year ago. Currently the most recent version is part of dstats:
http://dsimcha.github.com/dstats/docs/alloc.htmlhttps://github.com/dsimcha/dstats/blob/master/alloc.d