On Tue, Dec 9, 2008 at 2:53 PM, Daniel White <twinbee42@skytopia.com> wrote:
> 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.

For interaction with some C libraries.  Or for implementing your own memory management without having to deal with the GC.

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

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

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.