When is it time for a 1.0 feature freeze?

[Walter Bright]

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.

You're right, I haven't tried every implementation, and don't know it 
for a fact. It's just true of every one I've looked at, and there are 3 
good reasons for it to be so:

1) Speed
2) Speed
3) Speed

<g>

If your app isrelying on free/delete returning memory to the operating 
system, you really need to take a good hard look at the implementation 
of it, because it isn't.

Ironically, it's much more likely that a gc will return memory to the os 
- because a gc can be a copying collector, meaning it can compact the 
used memory and free the rest. free/delete cannot do any compaction, 
meaning it's unlikely to be able to release any memory back to the os 
due to fragmentation, minimum page sizes, and the high water nature of 
allocating memory to a task.

It's often moot anyway, since as I wrote before, runtime heap management 
  is holding on to virtual memory, not physical memory. A gc again has 
the potential advantage here, as it can compact the actual used memory 
into as few pages as possible, reducing physical memory consumption, and 
increasing the working set that will fit into the cache.

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

The spec has nothing to say about it.