http://d.puremagic.com/issues/show_bug.cgi?id=3696

           Summary: SuperStack
           Product: D
           Version: 2.036
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: sean@invisibleduck.org
        ReportedBy: chadjoan@gmail.com


--- Comment #0 from Chad Joan <chadjoan@gmail.com> 2010-01-11 17:32:03 PST ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3696


Alex Rønne Petersen <alex@lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alex@lycus.org
         Resolution|                            |WONTFIX


--- Comment #1 from Alex Rønne Petersen <alex@lycus.org> 2012-10-10 03:42:22 CEST ---
Let's open an issue if there is actual interest or someone provides a patch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3696



--- Comment #2 from Chad Joan <chadjoan@gmail.com> 2012-10-09 19:08:23 PDT ---
(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 :/

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3696



--- Comment #3 from Alex Rønne Petersen <alex@lycus.org> 2012-10-10 04:19:20 CEST ---
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.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3696



--- Comment #4 from Chad Joan <chadjoan@gmail.com> 2012-10-09 19:21:01 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3696


Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com


--- Comment #5 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-10-10 00:31:39 PDT ---
(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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------