www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2306] New: Scope for dynamic arrays should free memory.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306

           Summary: Scope for dynamic arrays should free memory.
           Product: D
           Version: 2.018
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: minor
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: dsimcha yahoo.com


Because of the overhead of frequent garbage collections, as well as false
pointer issues with conservative GC, it is sometimes desirable to use
RAII-style memory management for large arrays.  Most RAII stuff in D is done
using the scope keyword.  However, when applied to dynamic arrays, the scope
keyword apparently does absolutely nothing.  The following program runs out of
memory after 3 iterations due to false pointer issues, as is expected when
allocating a 400 MB array in 4 GB address space w/ conservative GC as the only
method being used to free memory.

import std.stdio;

void main() {
    uint count = 0;
    while(true) {
        test();
        writefln(++count);
    }
}

void test() {
    scope uint[] foo = new uint[100_000_000];
}

However, the following actually runs indefinitely:

import std.stdio;

void main() {
    uint count = 0;
    while(true) {
        test();
        writefln(++count);
    }
}

void test() {
    uint[] foo = new uint[100_000_000];
    scope(exit) delete foo;
}

This isn't a very serious bug, since there's an obvious, simple workaround, but
it's still an inconsistency in the language design, and ideally should be
fixed.


--
Aug 22 2008
next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306






In fact, it shouldn't allocate in the first place (in my opinion). C99 is able
to stack-allocate arrays and so should D:

void test(int size)
{
    int[size] stackAllocatedStaticArray;
    scope int[] stackAllocatedDynamicArray = new int[size];

    //exactly the same as the following:
    // int[size] tmp;
    // int[] stackAllocatedDynamicArray = tmp[0..$];
}


--
Aug 24 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
<d-bugmail puremagic.com> wrote in message 
news:g8s576$2ehd$1 digitalmars.com...

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






 In fact, it shouldn't allocate in the first place (in my opinion). C99 is 
 able
 to stack-allocate arrays and so should D:

 void test(int size)
 {
    int[size] stackAllocatedStaticArray;
    scope int[] stackAllocatedDynamicArray = new int[size];

    //exactly the same as the following:
    // int[size] tmp;
    // int[] stackAllocatedDynamicArray = tmp[0..$];
 }


 -- 


test(50000000);
Aug 24 2008
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 25 Aug 2008 02:07:41 +0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:


 <d-bugmail puremagic.com> wrote in message
 news:g8s576$2ehd$1 digitalmars.com...

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






 In fact, it shouldn't allocate in the first place (in my opinion). C99  
 is
 able
 to stack-allocate arrays and so should D:

 void test(int size)
 {
    int[size] stackAllocatedStaticArray;
    scope int[] stackAllocatedDynamicArray = new int[size];

    //exactly the same as the following:
    // int[size] tmp;
    // int[] stackAllocatedDynamicArray = tmp[0..$];
 }


 --


 test(50000000);


Stack overflow, do you expect anything else?
Aug 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306






I'd disagree that scope dynamic arrays should be stack allocated.  The
int[variableSize] syntax for that is perfectly good, if Walter wants to
implement it.  If you're allocating a very large array, you probably don't want
to allocate it on the stack so you don't overflow the stack.  Furthermore, you
can't resize stack allocated arrays after they're created, at least not in C99.


--
Oct 10 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306






For a possible resolution to this, see
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=79672.
 It's a post by Andrei describing a second stack on which objects like this
could be allocated.  If such a second stack could be built into the runtime,
all scope objects could be allocated there.


--
Nov 17 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306








 I'd disagree that scope dynamic arrays should be stack allocated.  The
 int[variableSize] syntax for that is perfectly good, if Walter wants to
 implement it.  If you're allocating a very large array, you probably don't want
 to allocate it on the stack so you don't overflow the stack.


I take my words back. I believe now it is up to the compiler to decide where to
put that scope array.


 Furthermore, you can't resize stack allocated arrays after they're created, at
least not in C99.


Well, yes and no. You can't resize C99-like variable-length array because it is
supposed to behave like a static one. But scope T[] array may be easily resized
even if it is stack allocated and initially points to stack. It could cause
some problems if array data would be realloc'ated upon resize (you may end up
with trying to reallocate stack space), but since it doesn't and old array is
left for garage collector recycling, your data will be moved to heap after
firrst array resize while a copy of them stays on stack until you leave the
scope:

P.S. Now that I wrote the last sentence I start wondering if it really behaves
as I think :) Is the array resize policy documented anywhere?


--
Nov 19 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306








 void test() {
     scope uint[] foo = new uint[100_000_000];
 }
 void test() {
     uint[] foo = new uint[100_000_000];
     scope(exit) delete foo;
 }
 
 This isn't a very serious bug, since there's an obvious, simple workaround, but
 it's still an inconsistency in the language design, and ideally should be
 fixed.
 


consider this
-----
void test() {
    scope uint[] foo = new uint[100_000_000];
    scope uint[] foo1 = foo;
}
-----
how much should it free?


--
Dec 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306








 
 consider this
 -----
 void test() {
     scope uint[] foo = new uint[100_000_000];
     scope uint[] foo1 = foo;
 }
 -----
 how much should it free?
 


I guess this is where the T[new] and T[] types that have been proposed come in.
 foo would be T[new] so it would determine the freeing stuff. foo1 would be
T[], so it wouldn't.


--
Dec 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306


David Simcha <dsimcha yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



I'm closing this since we're doing away with scope classes and moving them to a
library solution.  The corresponding library solution for arrays is
std.container.Array.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |nfxjfg gmail.com
            Version|2.018                       |D1
         Resolution|WONTFIX                     |
         OS/Version|Windows                     |All
           Severity|minor                       |enhancement



Still valid for D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



I think D1 is feature-frozen, I don't think this will be ever added by Walter.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax gmail.com



PDT ---


 I think D1 is feature-frozen, I don't think this will be ever added by Walter.


But this is not a feature request, is a bug report.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 11 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2306




Nobody knows whether this is a bug report or an enhancement request because D1
is too underspecified.

Walter has added features to D1 in the past, although I suspect he's keeping
that low to advertise D2.

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