Bug 2306 – Scope for dynamic arrays should free memory.

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.

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..$]; }

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.

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.

(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?

(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?

(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.

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.

Still valid for D1.

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

(In reply to comment #9) > 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.

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.

D1 is not maintained anymore and now we have a library solution for scope classes in std.typecons.scoped.