When is it time for a 1.0 feature freeze?
Walter Bright
newshound at digitalmars.com
Sun Sep 3 02:09:32 PDT 2006
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.
More information about the Digitalmars-d
mailing list