[Issue 3696] New: SuperStack

[d-bugmail at puremagic.com]

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 at invisibleduck.org
        ReportedBy: chadjoan at gmail.com


--- Comment #0 from Chad Joan <chadjoan at 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: -------