Jump to page: 1 2
Thread overview
[Issue 2306] New: Scope for dynamic arrays should free memory.
Aug 23, 2008
d-bugmail
Aug 24, 2008
d-bugmail
Aug 25, 2008
Denis Koroskin
Oct 11, 2008
d-bugmail
Nov 18, 2008
d-bugmail
Nov 20, 2008
d-bugmail
Dec 11, 2008
d-bugmail
Dec 12, 2008
d-bugmail
Aug 11, 2010
David Simcha
Aug 11, 2010
nfxjfg@gmail.com
Aug 11, 2010
Leandro Lucarella
Aug 11, 2010
nfxjfg@gmail.com
August 23, 2008
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.


-- 

August 24, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2306





------- Comment #1 from 2korden@gmail.com  2008-08-24 12:19 -------
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..$];
}


-- 

August 24, 2008
<d-bugmail@puremagic.com> wrote in message news:g8s576$2ehd$1@digitalmars.com...
> http://d.puremagic.com/issues/show_bug.cgi?id=2306
>
>
>
>
>
> ------- Comment #1 from 2korden@gmail.com  2008-08-24 12:19 -------
> 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);


August 25, 2008
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
>>
>>
>>
>>
>>
>> ------- Comment #1 from 2korden@gmail.com  2008-08-24 12:19 -------
>> 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?
October 11, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2306





------- Comment #2 from dsimcha@yahoo.com  2008-10-10 21:11 -------
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.


-- 

November 18, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2306





------- Comment #3 from dsimcha@yahoo.com  2008-11-17 21:36 -------
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.


-- 

November 20, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2306





------- Comment #4 from 2korden@gmail.com  2008-11-19 20:07 -------
(In reply to comment #2)
> 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?


-- 

December 11, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2306





------- Comment #5 from maxmo@pochta.ru  2008-12-11 06:25 -------
(In reply to comment #0)
> 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?


-- 

December 12, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2306





------- Comment #6 from dsimcha@yahoo.com  2008-12-11 22:54 -------
(In reply to comment #5)
> 
> 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.


-- 

August 11, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=2306


David Simcha <dsimcha@yahoo.com> changed:

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


--- Comment #7 from David Simcha <dsimcha@yahoo.com> 2010-08-11 14:16:06 PDT ---
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: -------
« First   ‹ Prev
1 2