Delete does not really delete

[Hong Chen]

I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.

Goshiwen

[Victor Bazarov]

Hong Chen wrote:

I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.

I am not sure if this is in the FAQ (have you looked?) but about once
a month we get this question. Please post to the newsgroup that deals
with your platform. Whatever "performance monitor" tells you cannot
have anything to do with the language, and everything to do with your
OS.

Your guess about "heap allocator" and its relation to "future use" of
"deleted memory" is about as good as mine. Any way to "force the
release" would certainly be plaform-specific, don't you think?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Juha Nieminen]

Hong Chen wrote:

I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

In most OS's, when you allocate memory the program asks the OS to
increase the heap for the process. It never asks it to reduce it. (And
even if in some OS programs would have the means to do that, memory
fragmentation would probably often stop them from being able to do it.)

Thus in most OS's the memory taken by programs never decreases. OTOH
that's what swapping is for.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.

The default allocator used in C and C++ programs will reuse heap
memory whenever it can. That's not the problem.

[Paavo Helde]

Juha Nieminen <no****@thanks.invalidkirjutas:

Hong Chen wrote:

>I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

In most OS's, when you allocate memory the program asks the OS to
increase the heap for the process. It never asks it to reduce it. (And

At least the C++ implementatons and OS-es I have used do reduce the
process memory (Windows and Linux). There is some granularity though, it
used to be 1MB in Windows IIRC.

even if in some OS programs would have the means to do that, memory
fragmentation would probably often stop them from being able to do it.)

That's what the virtual address space is for. Maybe the typical size of a
single allocation also plays a role, if you have a single byte allocated
in each hardware memory page (4096 bytes for x86 IIRC), then you really
can't release any of them.

>
Thus in most OS's the memory taken by programs never decreases. OTOH
that's what swapping is for.

We routinely monitor the program workset memory as seen by OS and it
definitely decreases and increases (with megabyte granularity, but that's
ok for us).

>

>Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.

I bet the problem is somewhere else.

>
The default allocator used in C and C++ programs will reuse heap
memory whenever it can. That's not the problem.

That's true.

Best
Paavo

[Puppet_Sock]

On Jun 2, 7:12*pm, Hong Chen <[e-mail]:

I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.

There is also the possibility your freestore is fragmented.
If there are deleted chunks of memory in the middle of
the freestore, it is unlikely these will be given back
to the OS. Indeed, in extreme situations, you can wind
up walking your freestore and running out of memory when
you only have a very small amount of actually-used memory.

You can sometimes get a profiling tool to detect such
situations. (Though it's off topic here. Ask in a news
group dedicated to your compiler and operating system.)
If that is the case, and it is a problem, there are many
ways to approach the situation. For example, you can take
more direct control of memory allocation, in such ways
as allocating a bunch of a particular object, then you
can re-use them as needed. Such things as a the named
ctor idiom are good places to start your research.
Socks