When is it time for a 1.0 feature freeze?

[Gregor Richards]

Stewart Gordon wrote:
> Walter Bright wrote:
> <snip>
> 
>> 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.
> 
> <snip>
> 
> Never?  I can't believe you've tried every implementation out there, 
> including your own, and found the same.
> 
> Or does the spec forbid free or delete to return memory to the OS?  I 
> can't for the life of me see why this would be.
> 
> Stewart.
> 

In general changing the amount a process wishes to use (the data segment 
size) involves calling [s]brk.  brk just controls the pointer to the end 
of the memory you have available.  You can't get data segments in 
chunks, only one contiguous block.  Because of this, it's in general 
impossible for free/delete to return the memory to the OS, as it cannot 
move memory arbitrarily (or all the pointers would go funky), and it in 
all likelyhood has something allocated at the end of the data segment.

I don't know whether it's in any spec that this is how it MUST work, but 
this is how it USUALLY works.  There's no real reason to do otherwise, 
especially since changing it would make the data segmentation much more 
complicated.

  - Gregor Richards