When is it time for a 1.0 feature freeze?

[Walter Bright]

Serg Kovrov wrote:
> But that not worst part. Although I'm personally from C++ camp and I get 
> used to GC. and see it as good thing. But, there is one big BUT! 
> Currently GC do not return memory to OS, and that thing even I can't 
> subdue. The only reason I choose 'native' (as opposite to VM) 
> programming language is effective resource usage. I hate Java/.net gui 
> applications because their memory consuming. I really appreciate 
> developers that choose c/c++ to write small, memory effective, but yet 
> feature-reach applications like FileZilla Server, uTorrent or Miranda IM.
> 
> Most desktop applications (like text editors, news readers, web 
> browsers, etc) must coexist with each other. That is, to use memory 
> wisely and give it back if it not needed anymore. This 'upper water 
> mark' approach in GC is just not acceptable.

1) Few programmers realize that C/C++'s malloc/free/new/delete *never* 
(and I emphasize NEVER) return memory to the operating system. All 
free/delete do is return memory to the memory pool managed by the 
runtime library, not the operating system. In order to actually return 
memory to the operating system, one has to write their own memory 
management code, which is a significant (and necessarily non-portable) 
effort. Hardly anyone does that.

2) The GC's memory pool doesn't consist of physical memory, it consists 
of virtual memory. If that virtual memory is not being used, the 
operating system automatically swaps it out and allocates the physical 
memory to whoever actually uses it. The 'memory' held by the GC isn't 
memory at all, but nothing more than a range of addresses.

You can run out of virtual address space, but that's rare and usually 
indicates you've got a bug, such as an infinite loop allocating memory.

3) The GC could be modified to return unused address space to the 
operating system, that it doesn't do so now is not a limitation on D itself.

4) Given the exact same code, a gc'd program will consume roughly twice 
as much memory as the same explicitly allocated one (though neither will 
return memory to the operating system). But a program written to take 
advantage of GC can often use less memory (because it needs to make far 
fewer copies of things, and because it doesn't have to allocate extra 
memory management blocks like shared_ptr<T> does).

5) malloc/free/new/delete use an 'upper water mark' system of managing 
their internal free memory pools just like D's gc does.