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
Let's open an issue if there is actual interest or someone provides a patch.
(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 :/
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.)
(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.
(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.html https://github.com/dsimcha/dstats/blob/master/alloc.d