How to save RAM in D programs (on zero initialized buffers)

[Martin Nowak]

On Tue, 07 Feb 2012 21:37:03 +0100, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2012-02-07 20:24:40 +0000, "Marco Leise" <Marco.Leise at gmx.de> said:
>
>> Am 07.02.2012, 21:11 Uhr, schrieb Nick Sabalausky <a at a.a>:
>>
>>> Is void initialization not good enough?
>>>  IIRC it's something like:
>>>  ubyte[] buf = void;
>>  That gives me a) no buffer, who's pointer is b) not initialized to  
>> null.
>> I want instead a defined pointer, to a valid array, that is initialized  
>> to  zero.
>>  Anyway, I think the flaw in my proposal is the use of a GC. Since we  
>> don't  get the memory directly from the operating system, but from a  
>> memory pool  in the GC, it is generally 'recycled' and already used  
>> memory. It has to  be zeroed out manually, unless there was a way to  
>> tell the OS to rebind  some virtual memory addresses in our program to  
>> this magic 'zero page'.
>
> What would be nice is a GC that would just track system-allocated memory  
> blocks. What would be really great is if you could allocate a block with  
> malloc/calloc (or something else) and later pass ownership to the GC, so  
> that the GC calls free (or something else) when all references  
> disappear. But I'm not sure how you can do that efficiently.
>

A similar idea popped up to solve non-deterministic shared library  
unloading
and/or mapped memory freeing.
I'm don't think though that putting additional pressure on the GC is the  
right
approach to resource management.

The interface would be simple for non-overlapping ranges.
void GC.trackRange(void* p, size_t sz, void delegate() finalizer)