• James Miller (24/24) Apr 02 2012 I've been doing some reading on dlang.org and the newsgroup archives
• Timon Gehr (16/35) Apr 03 2012 Custom allocators are important for performance optimization. Manual

James Miller <james aatch.net> writes:

I've been doing some reading on dlang.org and the newsgroup archives
and have seen talk about allocators and things around the garbage
collector.

I have a few questions about the entire thing:

- I understand that allocators are all about memory management, but
how does this affect D and the way allocators are integrated into the
language?
- How are allocators supposed to work with the GC? I know that you can
manually allocate memory and add the range to the GC, but why do you
have to do this?
- I've read that custom allocators aren't implemented, but I see
references to using new() and delete() in classes in the docs? Is this
one of the cases where the docs are "what it should be" and the
reality is different? If there aren't custom allocators, then are
there any major blockers to the addition (or is it just "because
nobody has added it"?)?
- Would it be possible to use custom allocators to write a completely
GC-free application (using ref-counting instead for example)? Or would
the GC still be used anyway?

If I'm way off base on anything, feel free to say so, memory
management and garbage collection aren't exactly my strong suits.

Thanks

--
James Miller

Timon Gehr <timon.gehr gmx.ch> writes:

On 04/03/2012 05:47 AM, James Miller wrote:
 I've been doing some reading on dlang.org and the newsgroup archives
 and have seen talk about allocators and things around the garbage
 collector.

 I have a few questions about the entire thing:

 - I understand that allocators are all about memory management, but
 how does this affect D and the way allocators are integrated into the
 language?

Custom allocators are important for performance optimization. Manual 
memory management is already possible and does not require language changes.

 - How are allocators supposed to work with the GC? I know that you can
 manually allocate memory and add the range to the GC, but why do you
 have to do this?

You can manually allocate memory and not add the range to the GC as long 
as the range does not contain pointers to the GC heap.

 - I've read that custom allocators aren't implemented, but I see
 references to using new() and delete() in classes in the docs? Is this
 one of the cases where the docs are "what it should be" and the
 reality is different? If there aren't custom allocators, then are
 there any major blockers to the addition (or is it just "because
 nobody has added it"?)?

Custom new() and delete() are in the compiler, but Andrei wants them to 
go away. (IIRC he also wanted to deprecate the 'new'-expression some 
time ago.)

Note that custom new() and delete() are not to be used synonymous with 
the notion of custom allocators. They just provide a hook for custom 
allocators.

 - Would it be possible to use custom allocators to write a completely
 GC-free application (using ref-counting instead for example)?

Ref-counting is a form of automated GC.

 Or would the GC still be used anyway?

AFAIK you can modify the runtime library so that it does not export the 
GC at all and still get working code.


Also see std.conv.emplace:
http://dlang.org/phobos/std_conv.html#emplace