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

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.

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

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?

"Daniel White" 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

On Tue, Dec 9, 2008 at 9:16 AM, Daniel White <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).

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, Daniel White <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.

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

On Tue, Dec 9, 2008 at 11:08 AM, Daniel White <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.

Jarrett Billingsley Wrote:

> On Tue, Dec 9, 2008 at 11:08 AM, Daniel White <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.