www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Freeing of memory (garbage collection)

reply Dan W <twinbee42 skytopia.com> writes:
A couple of questions:

1: Even though D has an automatic garbage collector, is one still
allowed to free the memory of a malloced array manually (using free
() ), to avoid pauses in the program?

2: One justification on the website for using automatic garbage
collection is how "allocated memory will only be freed if system RAM
is tight". But surely that's silly, since one may want *lots* of
memory free for a completely different application (merely memory
being 'tight' before freeing may not be good enough - one may want D
to free memory sooner).
Dec 08 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Dan,


 A couple of questions:
 
 1: Even though D has an automatic garbage collector, is one still
 allowed to free the memory of a malloced array manually (using free ()
 ), to avoid pauses in the program?
 


Yes, in fact if you malloc memory you MUST free it. Only stuff like dynamic 
arrays, AAs and new'ed stuff gets cleaned up by the GC.


 2: One justification on the website for using automatic garbage
 collection is how "allocated memory will only be freed if system RAM
 is tight". But surely that's silly, since one may want *lots* of
 memory free for a completely different application (merely memory
 being 'tight' before freeing may not be good enough - one may want D
 to free memory sooner).
 


With virtual memory and swap space, this (almost) no longer matters. If you 
aren't using memory sooner or later it's not using your RAM but just sitting 
on the disk.
Dec 08 2008
parent reply Dan <twinbee42 skytopia.com> writes:
Thanks for that reply. I wonder if extending automatic garbage
collection for malloced memory would be a good idea...


 Only stuff like dynamic 
 arrays, AAs and new'ed stuff gets cleaned up by the GC.


For the above types of allocating memory, is there a way to 'lock' a
variable and say to D, "don't free this memory until I allow you to",
and also for it to allow you to free it manually when/if need be?
Dec 09 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Dan" wrote

 Thanks for that reply. I wonder if extending automatic garbage
 collection for malloced memory would be a good idea...


 Only stuff like dynamic
 arrays, AAs and new'ed stuff gets cleaned up by the GC.


 For the above types of allocating memory, is there a way to 'lock' a
 variable and say to D, "don't free this memory until I allow you to",
 and also for it to allow you to free it manually when/if need be?


One thing you can do, that nobody has mentioned yet, is delete memory that 
you have allocated using the GC.

Deleting a block of memory that the GC has allocated allows you to reuse 
that memory without going through a full GC collect cycle, and so most 
likely your performance will be better.  Using delete in key spots can be 
good.

But using manual memory mangement prevents lots of good designs, so use with 
caution.

Lastly, if you are allocating lots of temporary classes, try declaring them 
as scope.  This allocates the class on the stack if possible.  Note that any 
memory allocated by the constructor will still go through the GC.  Also note 
that you can't use a scoped class once its scope is finished.  e.g.:
class C
{ ... }

...

while(x > 0)
{
   scope c = new C(x--); // c is allocated on the stack.  scope keyword 
implies the type.
   c.doSomething();
   // c is deleted from stack at end of loop iteration.  No heap activity.
}

-Steve
Dec 09 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 One thing you can do, that nobody has mentioned yet, is delete memory that 
 you have allocated using the GC.


Leaving the GC manage and free your memory is usually OK. Managing manually
your memory allocated from the C heap is doable. But freeing manually and
forcefully memory allocated by the GC seems dangerous to me.

Bye,
bearophile
Dec 09 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Dec 9, 2008 at 9:16 AM, Dan <twinbee42 skytopia.com> wrote:

 Thanks for that reply. I wonder if extending automatic garbage
 collection for malloced memory would be a good idea...


That would be a bad idea.  Then how would you do manual memory
management in the few cases that absolutely require it?


 Only stuff like dynamic
 arrays, AAs and new'ed stuff gets cleaned up by the GC.


 For the above types of allocating memory, is there a way to 'lock' a
 variable and say to D, "don't free this memory until I allow you to",
 and also for it to allow you to free it manually when/if need be?


Yes, you can use std.gc.addRoot in Phobos (in D1), and GC.addRoot if
you're using Tango (import tango.core.Memory) or D2 (import
core.memory).
Dec 09 2008
parent reply Dan <twinbee42 skytopia.com> writes:
 That would be a bad idea.  Then how would you do manual memory
 management in the few cases that absolutely require it?


Two ways. Either:

a: being able to lock the variable so that the garbage collector
can't touch it until you unlock it.

b: Using a slightly different version of malloc (say 'mallocl') which again,
makes it shielded against the garbage collector's wrath.
Dec 09 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Dec 9, 2008 at 11:08 AM, Dan <twinbee42 skytopia.com> wrote:

 That would be a bad idea.  Then how would you do manual memory
 management in the few cases that absolutely require it?


 Two ways. Either:

 a: being able to lock the variable so that the garbage collector
 can't touch it until you unlock it.


Why not just use GC-allocated memory and use addRoot then?


 b: Using a slightly different version of malloc (say 'mallocl') which again,
 makes it shielded against the garbage collector's wrath.


At which point you're back to the same situation as we have currently.
Dec 09 2008
parent reply Dan <twinbee42 skytopia.com> writes:
Jarrett Billingsley Wrote:


 On Tue, Dec 9, 2008 at 11:08 AM, Dan <twinbee42 skytopia.com> wrote:

 That would be a bad idea.  Then how would you do manual memory
 management in the few cases that absolutely require it?


 Two ways. Either:

 a: being able to lock the variable so that the garbage collector
 can't touch it until you unlock it.


 
 Why not just use GC-allocated memory and use addRoot then?


Well that question points at the deeper issue of why bother having malloc at
all.
Dec 09 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Dec 9, 2008 at 2:53 PM, Dan <twinbee42 skytopia.com> wrote:

 Jarrett Billingsley Wrote:


 On Tue, Dec 9, 2008 at 11:08 AM, Dan <twinbee42 skytopia.com> wrote:

 That would be a bad idea.  Then how would you do manual memory
 management in the few cases that absolutely require it?


 Two ways. Either:

 a: being able to lock the variable so that the garbage collector
 can't touch it until you unlock it.


 Why not just use GC-allocated memory and use addRoot then?


 Well that question points at the deeper issue of why bother having malloc at
all.


For interaction with some C libraries.  Or for implementing your own
memory management without having to deal with the GC.
Dec 09 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Dan wrote:

 That would be a bad idea.  Then how would you do manual memory
 management in the few cases that absolutely require it?


 
 Two ways. Either:
 
 a: being able to lock the variable so that the garbage collector
 can't touch it until you unlock it.


If you have a reference to the memory, the GC won't collect it. Unless 
you make a habit of hiding pointers inside non-pointer types, that is, 
which can result in undefined behavior if the hidden pointer points to 
GC-allocated memory.

If you don't have any reference to that memory, then the garbage 
collector can free it, but in that case, I don't see why it would be an 
issue, most of the time. If you have a destructor, just be careful -- 
for instance, if you have an open file in that object and its destructor 
closes that file.


 b: Using a slightly different version of malloc (say 'mallocl') which again,
 makes it shielded against the garbage collector's wrath.


malloc is C stdlib malloc. The garbage collector won't touch it.
Dec 09 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Dec 9, 2008 at 9:42 AM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Tue, Dec 9, 2008 at 9:16 AM, Dan <twinbee42 skytopia.com> wrote:

 Thanks for that reply. I wonder if extending automatic garbage
 collection for malloced memory would be a good idea...


 That would be a bad idea.  Then how would you do manual memory
 management in the few cases that absolutely require it?


 Only stuff like dynamic
 arrays, AAs and new'ed stuff gets cleaned up by the GC.


 For the above types of allocating memory, is there a way to 'lock' a
 variable and say to D, "don't free this memory until I allow you to",
 and also for it to allow you to free it manually when/if need be?


 Yes, you can use std.gc.addRoot in Phobos (in D1), and GC.addRoot if
 you're using Tango (import tango.core.Memory) or D2 (import
 core.memory).


Oh yeah, and you can use 'delete' on arrays, classes, and structs
allocated on the heap, but oddly not with AAs.
Dec 09 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Dan W:

 1: Even though D has an automatic garbage collector, is one still
 allowed to free the memory of a malloced array manually (using free
 () ), to avoid pauses in the program?


Other people here will just answer your question. But remember that in D manual
memory management is done only in special situations, most code of most
programs just use the GC.

Bye,
bearophile
Dec 09 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 9 Dec 2008 03:25:07 +0000 (UTC), Dan W wrote:


 1: Even though D has an automatic garbage collector, is one still
 allowed to free the memory of a malloced array manually (using free
 () ), to avoid pauses in the program?


Just to clarify.  There are 3 types of allocation:

1.  std.c.stdlib.malloc().  The good ol' plain C allocation which is
entirely manual and requires std.c.stdlib.free() to free memory.

2.  std.gc.malloc(), or tango.core.Memory.GC.malloc(), or
core.memory.GC.malloc() in recent D2.  These allocate an uninitialized
but GC-managed and GC-scanned by default memory.  That is, this memory
gets automatically freed as soon as there are no GC-managed references
to it.  You can explicitly free this memory using the delete keyword.
You can direct GC not to scan this memory for pointers using
std.gc.hasNoPointers() or equivalent.

3.  Memory allocated via new, arrays, etc.  This memory is GC-managed
but can be freed explicitly using the delete keyword.


 2: One justification on the website for using automatic garbage
 collection is how "allocated memory will only be freed if system RAM
 is tight". But surely that's silly, since one may want *lots* of
 memory free for a completely different application (merely memory
 being 'tight' before freeing may not be good enough - one may want D
 to free memory sooner).


I don't think this is a valid justification.  One of the main GC
justifications is an ability to implement flexible data models where
data owner is uncertain or unknown.  In such cases GC makes it easy to
avoid data duplication.
Dec 13 2008