www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Deallocate array?

reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
Hi

I'm running Windows Vista 64 with dmd 2.062.

I have a simple program:

import std.stdio, core.memory, std.cstream;
void main()
{
	string[] temp_array;

	for(int i=0;i<5000000;i++)
	{
		++temp_array.length;
		temp_array[temp_array.length - 1] = "aaaaaaaaaaaaaaaaaaaaa";
	}
	
	temp_array = null;

	GC.collect();
         writeln("end");	
	din.getc();
}

When the program waits at "din.getc();", memory usage in the Task 
Manager is 150MB.

Why isn't the memory deallocating?

P.S.;
I tried temp_array.clear() and destroy(temp_array), but nothing 
changed.
May 07 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/07/2013 04:09 PM, Matic Kukovec wrote:> Hi

 When the program waits at "din.getc();", memory usage in the Task
 Manager is 150MB.

 Why isn't the memory deallocating?

 P.S.;
 I tried temp_array.clear() and destroy(temp_array), but nothing changed.
GC.minimize() may work. Ali
May 07 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
On Tuesday, 7 May 2013 at 23:14:20 UTC, Ali Çehreli wrote:
 On 05/07/2013 04:09 PM, Matic Kukovec wrote:> Hi

 When the program waits at "din.getc();", memory usage in the
Task
 Manager is 150MB.

 Why isn't the memory deallocating?

 P.S.;
 I tried temp_array.clear() and destroy(temp_array), but
nothing changed. GC.minimize() may work. Ali
Thanks for the quick reply, Ali. Tried it, no changes.
May 07 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/07/2013 04:18 PM, Matic Kukovec wrote:

 On Tuesday, 7 May 2013 at 23:14:20 UTC, Ali Çehreli wrote:
 GC.minimize() may work.
 Tried it, no changes.
Works for your test program under Linux but as the documentation says, it is not guaranteed to have any effect at all. Ali
May 07 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
On Tuesday, 7 May 2013 at 23:31:41 UTC, Ali Çehreli wrote:
 On 05/07/2013 04:18 PM, Matic Kukovec wrote:

 On Tuesday, 7 May 2013 at 23:14:20 UTC, Ali Çehreli wrote:
 GC.minimize() may work.
 Tried it, no changes.
Works for your test program under Linux but as the documentation says, it is not guaranteed to have any effect at all. Ali
I found this problem with a program that reads a large xml file (250000+ lines), then stores the lines in a string[], does a comparison with another array and finally clears the original array. On the second or third file I always get an OutOfMemoryError, when the Task Manager shows about 1.3GB memory usage. Is this a Windows specific thing or am I doing something wrong?
May 07 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/07/2013 04:42 PM, Matic Kukovec wrote:

 On Tuesday, 7 May 2013 at 23:31:41 UTC, Ali Çehreli wrote:
 On 05/07/2013 04:18 PM, Matic Kukovec wrote:

 On Tuesday, 7 May 2013 at 23:14:20 UTC, Ali Çehreli wrote:
 GC.minimize() may work.
 Tried it, no changes.
Works for your test program under Linux but as the documentation says, it is not guaranteed to have any effect at all. Ali
I found this problem with a program that reads a large xml file (250000+ lines), then stores the lines in a string[], does a comparison with another array and finally clears the original array.
You don't need to clear the original array but it should be harmless.
 On the second or third file I always get an OutOfMemoryError, when the
 Task Manager shows about 1.3GB memory usage.

 Is this a Windows specific thing or am I doing something wrong?
Is this a 32-bit platform? If so, the reason may be the conservative GC that dmd uses. What happens is, unrelated 32-bit values in other parts of the program may look like pointers into the allocated space and the GC thinks that they are still in use. Ali
May 07 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
On Tuesday, 7 May 2013 at 23:58:53 UTC, Ali Çehreli wrote:
 On 05/07/2013 04:42 PM, Matic Kukovec wrote:

 On Tuesday, 7 May 2013 at 23:31:41 UTC, Ali Çehreli wrote:
 On 05/07/2013 04:18 PM, Matic Kukovec wrote:

 On Tuesday, 7 May 2013 at 23:14:20 UTC, Ali Çehreli wrote:
 GC.minimize() may work.
 Tried it, no changes.
Works for your test program under Linux but as the
documentation says,
 it is not guaranteed to have any effect at all.

 Ali
I found this problem with a program that reads a large xml
file (250000+
 lines), then stores the lines in a string[], does a
comparison with
 another array and finally clears the original array.
You don't need to clear the original array but it should be harmless.
 On the second or third file I always get an OutOfMemoryError,
when the
 Task Manager shows about 1.3GB memory usage.

 Is this a Windows specific thing or am I doing something
wrong? Is this a 32-bit platform? If so, the reason may be the conservative GC that dmd uses. What happens is, unrelated 32-bit values in other parts of the program may look like pointers into the allocated space and the GC thinks that they are still in use. Ali
The system is Windows Vista 64bit. DMD is 2.062.
May 07 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Matic Kukovec:

 The system is Windows Vista 64bit. DMD is 2.062.
DMD doesn't yet produce 64 bit binaries on Windows. I have tried to solve your problem using GC.free, but I am not seeing good results... Bye, bearophile
May 07 2013
prev sibling parent "Juan Manuel Cabo" <juanmanuel.cabo gmail.com> writes:
 I found this problem with a program that reads a large xml file 
 (250000+ lines), then stores the lines in a string[], does a 
 comparison with another array and finally clears the original 
 array.
 On the second or third file I always get an OutOfMemoryError, 
 when the Task Manager shows about 1.3GB memory usage.

 Is this a Windows specific thing or am I doing something wrong?
Try the following before getting rid of your arrays: myarray[] = null; //if it is an array of classes or strings myIntArray[] = 0; //if it is an array of ints myBigString[] = '\0'; etc. This clears the contents of the arrays, and helps the garbage collector, so that it doesn't confuse data with pointers. Also, avoid growing arrays little by little. This is VERY bad for garbage accumulation. Use instead an appender!(string[])() for string arrays for instance. --jm
May 07 2013
prev sibling next sibling parent "Juan Manuel Cabo" <juanmanuel.cabo gmail.com> writes:
 Why isn't the memory deallocating?
The memory might be free, but still not released to the OS. Especially in windows, when you free memory it still isn't freed from your process. But you can reuse it in your program if the GC has collected it. The correct test would be to copy and paste the same code below, and see if it stays at 150Mb or it jumps to 300Mb. If it jumps to 300Mb, then the GC hasn't collected it. If it stays at 150Mb, the GC had collected it but windows didn't claim it. --jm
May 07 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 07 May 2013 19:09:28 -0400, Matic Kukovec  
<matic.kukovec pametnidom.si> wrote:

 Hi

 I'm running Windows Vista 64 with dmd 2.062.

 I have a simple program:

 import std.stdio, core.memory, std.cstream;
 void main()
 {
 	string[] temp_array;

 	for(int i=0;i<5000000;i++)
 	{
 		++temp_array.length;
 		temp_array[temp_array.length - 1] = "aaaaaaaaaaaaaaaaaaaaa";
This is very inefficient, use temp_array ~= "aaaaaaaaaaaaaaaaaaaaa";
 	}
 	
 	temp_array = null;

 	GC.collect();
          writeln("end");	
 	din.getc();
 }

 When the program waits at "din.getc();", memory usage in the Task  
 Manager is 150MB.

 Why isn't the memory deallocating?
The GC does not return free memory to the OS, just to free memory pools/free-lists. GC.minimize may or may not help. But your code may not have freed that memory anyway. It is not really possible to ensure that temp_array isn't referred to. For example, the compiler could keep temp_array in a register.
 P.S.;
 I tried temp_array.clear() and destroy(temp_array), but nothing changed.
Neither of these will deallocate memory. All are equivalent to setting temp_array = null. If you want to ensure deallocation, you need to free it using GC.free(temp_array.ptr). A very dangerous operation, use with caution, make sure there are no other references to that data. -Steve
May 07 2013
parent "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
Thanks you guys for all the suggestions.

bearophile:
I am not creating 64 bit binaries. Tried compiling with or 
without the "-m32" flag.
I have played around with GC.free, see below for more details.

Juan Manuel Cabo:
I tried your methods, but no change.
The original program I described earlier used an Appender, but 
the result is the same.
I also copy/pasted the code twice (with or without 
GC.minimize()), to see if D was just reusing the memory, but the
memory jumped to 290MB so it is not being reused or freed.

Steven Schveighoffer:
I used the "++temp_array.length;" example, because it was 
straight from the dlang.org docs. In my original program i tried 
the "~=" first then an Appender.
In this example, if i use the "temp_array ~= 
"aaaaaaaaaaaaaaaaaaaaa";" the memory usage goes down from 150MB 
to about 80MB. Then i added:
temp_array = null;
GC.free(temp_array.ptr);
GC.minimize();
The memory goes down to about 40MB! But why not lower?
It also shrinks from 150MB to 100MB with the original 
"++temp_array.length;" apending to the array.
The program in now:
import std.stdio, core.memory, std.cstream;
void main()
{
	string[] temp_array;

	for(int i=0;i<5000000;i++)
	{
		temp_array ~= "aaaaaaaaaaaaaaaaaaaaa";
	}
	
	temp_array[] = null;
	
	GC.free(temp_array.ptr);
	GC.minimize();
	
	writeln("end");	

	din.getc();
}

Any ideas?
May 08 2013
prev sibling parent reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Tuesday, 7 May 2013 at 23:09:29 UTC, Matic Kukovec wrote:
 Hi

 I'm running Windows Vista 64 with dmd 2.062.

 I have a simple program:

 import std.stdio, core.memory, std.cstream;
 void main()
 {
 	string[] temp_array;

 	for(int i=0;i<5000000;i++)
 	{
 		++temp_array.length;
 		temp_array[temp_array.length - 1] = "aaaaaaaaaaaaaaaaaaaaa";
 	}
 	
 	temp_array = null;

 	GC.collect();
         writeln("end");	
 	din.getc();
 }

 When the program waits at "din.getc();", memory usage in the 
 Task Manager is 150MB.

 Why isn't the memory deallocating?

 P.S.;
 I tried temp_array.clear() and destroy(temp_array), but nothing 
 changed.
I guess the memory isn't freed because there is no need to do so. A garbage collector kicks in when there is not enough memory. In this case there is no need to.
May 08 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
On Wednesday, 8 May 2013 at 08:59:57 UTC, Minas Mina wrote:
 On Tuesday, 7 May 2013 at 23:09:29 UTC, Matic Kukovec wrote:
 Hi

 I'm running Windows Vista 64 with dmd 2.062.

 I have a simple program:

 import std.stdio, core.memory, std.cstream;
 void main()
 {
 	string[] temp_array;

 	for(int i=0;i<5000000;i++)
 	{
 		++temp_array.length;
 		temp_array[temp_array.length - 1] = "aaaaaaaaaaaaaaaaaaaaa";
 	}
 	
 	temp_array = null;

 	GC.collect();
        writeln("end");	
 	din.getc();
 }

 When the program waits at "din.getc();", memory usage in the 
 Task Manager is 150MB.

 Why isn't the memory deallocating?

 P.S.;
 I tried temp_array.clear() and destroy(temp_array), but 
 nothing changed.
I guess the memory isn't freed because there is no need to do so. A garbage collector kicks in when there is not enough memory. In this case there is no need to.
I don't think that is the case, because if i copy/paste: for(int i=0;i<5000000;i++) { ++temp_array.length; temp_array[temp_array.length - 1] = "aaaaaaaaaaaaaaaaaaaaa"; } temp_array = null; GC.collect(); 15 times and run the code, i get a core.exception.OutOfMemoryError. I don't know enough about D's garbage collection to figure out why the memory is not getting released/reused?
May 08 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
Was playing around with the code and found that this WORKS:
(note the "app_temp_array.reserve(50000000);" at the top, without 
this line it doesn't work)

import std.stdio, core.memory, std.cstream, std.array;
void main()
{
	string[] temp_array;
	Appender!(string[]) app_temp_array = appender(temp_array);
	app_temp_array.reserve(50000000);

	for(int i=0;i<50000000;i++)
	{
		app_temp_array.put("aaaaaaaaaaaaaaaaaaaaa");
	}
	
	temp_array = app_temp_array.data;
	
	app_temp_array.clear();
	GC.free(app_temp_array.data); or GC.free(temp_array.ptr);
	GC.collect();
	GC.minimize();
	
	writeln("end");	

	din.getc();
}

The memory usage shrinks from 400MB to 2MB, which is right!
Why?
May 08 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 May 2013 06:20:45 -0400, Matic Kukovec  
<matic.kukovec pametnidom.si> wrote:

 Was playing around with the code and found that this WORKS:
 (note the "app_temp_array.reserve(50000000);" at the top, without this  
 line it doesn't work)
[snip]
 The memory usage shrinks from 400MB to 2MB, which is right!
 Why?
This is the conservative garbage collector at work. What happens is there is a "false pointer", or a word-aligned 32-bit value on the stack, or in global registers, that points at one of the arrays that you allocate. As you append, and the GC needs to allocate larger and larger arrays to hold your new data, the old ones are left behind for the GC to collect. But some random integer somewhere happens to "point" at one of those arrays. It is then kept in memory. It doesn't have to be a large array. GC.minimize can only shrink the OS-provided memory block, which is sequential. If any data is still valid, even if there is a bunch of free pages below that data, it cannot be returned to the OS. When you reserve, however, one, and only one, memory block is allocated. This block you are explictly freeing at the end, so it will be collected. Then minimize can do a good job. Not saying you should do things this way, just explaining the behavior. arr.reserve is a good tool to use when you know how much data you will need. But it can't fix every situation. -Steve
May 08 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
On Wednesday, 8 May 2013 at 12:03:08 UTC, Steven Schveighoffer 
wrote:
 On Wed, 08 May 2013 06:20:45 -0400, Matic Kukovec 
 <matic.kukovec pametnidom.si> wrote:

 Was playing around with the code and found that this WORKS:
 (note the "app_temp_array.reserve(50000000);" at the top, 
 without this line it doesn't work)
[snip]
 The memory usage shrinks from 400MB to 2MB, which is right!
 Why?
This is the conservative garbage collector at work. What happens is there is a "false pointer", or a word-aligned 32-bit value on the stack, or in global registers, that points at one of the arrays that you allocate. As you append, and the GC needs to allocate larger and larger arrays to hold your new data, the old ones are left behind for the GC to collect. But some random integer somewhere happens to "point" at one of those arrays. It is then kept in memory. It doesn't have to be a large array. GC.minimize can only shrink the OS-provided memory block, which is sequential. If any data is still valid, even if there is a bunch of free pages below that data, it cannot be returned to the OS. When you reserve, however, one, and only one, memory block is allocated. This block you are explictly freeing at the end, so it will be collected. Then minimize can do a good job. Not saying you should do things this way, just explaining the behavior. arr.reserve is a good tool to use when you know how much data you will need. But it can't fix every situation. -Steve
Thanks for the explanation Steve. Can you please give me a correct example of: - creating a dynamic string array - looping over it and adding values - discarding/releasing the array from memory Thanks, Matic
May 08 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 May 2013 08:28:50 -0400, Matic Kukovec  
<matic.kukovec pametnidom.si> wrote:


 Thanks for the explanation Steve.

 Can you please give me a correct example of:
 - creating a dynamic string array
auto arr = new char[N]; N can be a runtime value.
 - looping over it and adding values
Not sure what you mean here.
 - discarding/releasing the array from memory
correct: arr = null; // GC should collect dangerous: GC.free(arr.ptr); Due to conservative GC, you may need to explicitly free memory for practical reasons (e.g. if GC doesn't seem to collect the data you release). This problem is MUCH less prevalent on 64-bit, since the memory space is quite sparse. -Steve
May 08 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
Hi again Steve, or anyone else whose reading this.

array stuff to work.

My D program:
import std.stdio, std.cstream, std.array;

void main()
{
	string[] temp_array = new string[100000000];
	for(int i=0;i<100000000;i++)
	{
		temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
	}		
	temp_array = null;
	
	temp_array = new string[100000000];
	for(int i=0;i<100000000;i++)
	{
		temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
	}
	temp_array = null;
	
	writeln("end");	

	din.getc();
}

This program causes an OutOfMemoryError.



using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace testing
{
     class Program
     {
         static void Main(string[] args)
         {

             string[] temp_array = new string[100000000];
             for (int i = 0; i < 100000000; i++)
             {
                 temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
             }
             temp_array = null;

             temp_array = new string[100000000];
             for (int i = 0; i < 100000000; i++)
             {
                 temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
             }
             temp_array = null;

             temp_array = new string[100000000];
             for (int i = 0; i < 100000000; i++)
             {
                 temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
             }
             temp_array = null;


             Console.WriteLine("end");
             Console.ReadKey(true);
         }
     }
}

It's the same program, but doesn't cause and OutOfMemory 
exception, even if i double the times i run the loop part.


D without running out of memory and preferably without using the 
GC directly?

I'm running Windows Vista 64bit, DMD 2.062 fresh install, 
compiling with "-m32" flag.
May 09 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/09/2013 05:58 PM, Matic Kukovec wrote:

 Hi again Steve, or anyone else whose reading this.

 stuff to work.
[...]

 without running out of memory and preferably without using the GC 
directly?
 I'm running Windows Vista 64bit, DMD 2.062 fresh install, compiling with
 "-m32" flag.
You have a string array of 100_000_000 elements. (You can insert underscores in literals to make code more readable.) On a 32-bit system string is 8 bytes (e.g. by pragma(msg, string.sizeof)). So you have a single array of 800 million bytes. Then, each of those strings point at 22 bytes of individully allocated memory areas. Note that 800 million is about 20% of the entire addressable memory of that system. If you have a single value that happens to look like a pointer into that memory, that huge block will remain in memory forever. The funny thing about dmd's current conservative GC is that even an integer can be mistaken to be a pointer into that memory. So that's the problem today. I don't know the exact requirement here but if you really must have 100 million strings at one time, then you may want to do your own memory management. The following should work: import std.stdio; import core.memory; void main() { enum size_t times = 10; enum size_t stringCount = 100_000_000; foreach (i; 0 .. times) { auto rawMemory = cast(string*)GC.calloc(string.sizeof * stringCount); // D's cool feature of making a slice from raw pointer auto tempArray = rawMemory[0 .. stringCount]; foreach (ref s; tempArray) { s = "aaaaaaaaaaaaaaaaaaaaa"; } GC.free(rawMemory); // You may want to set tempArray to null at this point to prevent // using it accidentally but it is not necessary. writefln("Done with allocation %s/%s; please press Enter", i + 1, times); readln(); } } Ali
May 09 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 May 2013 22:14:41 -0400, Ali =C3=87ehreli <acehreli yahoo.com=
 wrote:
 On a 32-bit system string is 8 bytes (e.g. by pragma(msg,  =
 string.sizeof)). So you have a single array of 800 million bytes. Then=
, =
 each of those strings point at 22 bytes of individully allocated memor=
y =
 areas.
No, each array points at static data. Strings are immutables stored in = = the data segment.
 Note that 800 million is about 20% of the entire addressable memory of=
=
 that system. If you have a single value that happens to look like a  =
 pointer into that memory, that huge block will remain in memory foreve=
r. =
 The funny thing about dmd's current conservative GC is that even an  =
 integer can be mistaken to be a pointer into that memory.

 So that's the problem today.
Correct, the only solution at the moment is to deallocate explicitly. r, = D = at GC as long as this is true. 64 bit address space also helps tremendously.
 I don't know the exact requirement here but if you really must have 10=
0 =
 million strings at one time, then you may want to do your own memory  =
 management. The following should work:

 import std.stdio;
 import core.memory;

 void main()
 {
      enum size_t times =3D 10;
      enum size_t stringCount =3D 100_000_000;

      foreach (i; 0 .. times) {
          auto rawMemory =3D cast(string*)GC.calloc(string.sizeof *  =
 stringCount);

          // D's cool feature of making a slice from raw pointer
          auto tempArray =3D rawMemory[0 .. stringCount];
You can allocate normally, and just use free on the pointer
          foreach (ref s; tempArray) {
              s =3D "aaaaaaaaaaaaaaaaaaaaa";
          }

          GC.free(rawMemory);
GC.free(tempArray.ptr); // also works
          // You may want to set tempArray to null at this point to  =
 prevent
          // using it accidentally but it is not necessary.

          writefln("Done with allocation %s/%s; please press Enter",
                   i + 1, times);
          readln();
      }
 }
-Steve
May 09 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/09/2013 07:43 PM, Steven Schveighoffer wrote:

 On Thu, 09 May 2013 22:14:41 -0400, Ali Çehreli <acehreli yahoo.com> 
wrote:
 Then, each of those strings point at 22 bytes of individully allocated
 memory areas.
No, each array points at static data. Strings are immutables stored in the data segment.
You are right. They start at pointing to the same string but as soon as each string is used in a special way, say each gets appended a char, then they own their special characters: s = "aaaaaaaaaaaaaaaaaaaaa"; // Some time later: s ~= 'x'; Now each s.ptr is different. Ali
May 09 2013
parent reply "Matic Kukovec" <matic.kukovec pametnidom.si> writes:
Thanks for the explanation guys.
Hope there will be improvements in D's GC in the future.

Also "delete temp_array" also works instead of 
"GC.free(temp_array.ptr)".
And you also need to call "GC.minimize()" after a 
delete/GC.free() if you want to shrink the memory use after the 
for loop:

         temp_array = new string[100000000];
	for(int i=0;i<100000000;i++)
	{
		temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
	}
	delete temp_array; or GC.free(temp_array.ptr);
	temp_array = null;
	GC.minimize();  //releases the memory, works without this line

Is "delete" safe for this kind of use?

Thanks guys
May 10 2013
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 10 May 2013 04:44:14 -0400, Matic Kukovec  
<matic.kukovec pametnidom.si> wrote:

 Thanks for the explanation guys.
 Hope there will be improvements in D's GC in the future.

 Also "delete temp_array" also works instead of "GC.free(temp_array.ptr)".
 And you also need to call "GC.minimize()" after a delete/GC.free() if  
 you want to shrink the memory use after the for loop:

          temp_array = new string[100000000];
 	for(int i=0;i<100000000;i++)
 	{
 		temp_array[i] = "aaaaaaaaaaaaaaaaaaaaa";
 	}
 	delete temp_array; or GC.free(temp_array.ptr);
 	temp_array = null;
 	GC.minimize();  //releases the memory, works without this line

 Is "delete" safe for this kind of use?
Delete is unsafe. It is being deprecated actually (not sure when). Becuase it cannot zero out all pointers that reference that data, you can have dangling pointers to the data. delete is replaced by the function destroy, which finalizes data, and GC.free to deallocate. Only the GC.free part is unsafe, destroy is OK to use. However, for arrays, destroy is equivalent to setting the value to null. -Steve
May 10 2013