www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3696] New: SuperStack

reply d-bugmail puremagic.com writes:
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



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: -------
Jan 11 2010
next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Oct 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3696






 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: -------
Oct 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3696




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: -------
Oct 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3696






 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: -------
Oct 09 2012
prev sibling parent d-bugmail puremagic.com writes:
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



00:31:39 PDT ---




 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: -------
Oct 10 2012